[Intel-gfx] [PATCH 2/2] drm/i915: Add compiler barrier to wait_for

Chris Wilson chris at chris-wilson.co.uk
Fri Apr 20 13:52:54 UTC 2018


Quoting Mika Kuoppala (2018-04-20 14:45:50)
> We need to be careful to not let compiler evaluate
> the expiration and the operation on it's terms.
> 
> Document and enforce that COND will be evaluated
> before checking timeout expiration.
> 
> Suggested-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Signed-off-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_drv.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index ac7565220aa3..4dc346716bb4 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -56,6 +56,8 @@
>         for (;;) {                                                      \
>                 const bool expired__ = ktime_after(ktime_get_raw(), end__); \
>                 OP;                                                     \
> +               /* Guarantee COND check prior to timeout */             \
> +               barrier();                                              \

Which side of OP is debatable, since OP is caller supplied and our
constraint is targeted at expired__. However, it is likely to be more
useful between OP/COND, so I can see some advantage there.

As Mika noted, moving to a function call should mean that the compiler
has less freedom to reorder/re-evaluate but doesn't completely prevent
it. As such being clear about the order of operations here is just as
important for the reader. There is a long history of gotchas here, and
this patch set continues the trend :)

Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris


More information about the Intel-gfx mailing list