As explained in the comments, a progress label wants to be before the function
it refers to for the higher level logic to make sense. As it happens, the
effects are benign because gnttab_mappings is immediately adjacent to teardown
in terms of co-routine exit points.
There is and will always be a corner case with 0. Help alleviate this
visually (at least slightly) with a BUILD_BUG_ON() to ensure the property
which makes this function do anything useful.
There is also a visual corner case when changing from PROGRESS() to
PROGRESS_VCPU(). The important detail is to check that there is a "return
rc;" logically between each PROGRESS*() marker.
Fixes: b1ee10be5625 ("gnttab: add preemption check to gnttab_release_mappings()")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
};
case PROG_none:
+ BUILD_BUG_ON(PROG_none != 0);
+
+ PROGRESS(gnttab_mappings):
rc = gnttab_release_mappings(d);
if ( rc )
return rc;
- PROGRESS(gnttab_mappings):
for_each_vcpu ( d, v )
{
PROGRESS_VCPU(teardown);