[Intel-gfx] [PATCH 01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

[Joonas Lahtinen]

On ma, 2016-08-08 at 10:45 +0100, Chris Wilson wrote:
> On Mon, Aug 08, 2016 at 10:30:25AM +0100, Chris Wilson wrote:
> > 
> > On Mon, Aug 08, 2016 at 11:12:59AM +0200, Daniel Vetter wrote:
> > > 
> > > On Sun, Aug 07, 2016 at 03:45:09PM +0100, Chris Wilson wrote:
> > > > 
> > > > In the debate as to whether the second read of active->request is
> > > > ordered after the dependent reads of the first read of active->request,
> > > > just give in and throw a smp_rmb() in there so that ordering of loads is
> > > > assured.
> > > > 
> > > > v2: Explain the manual smp_rmb()
> > > > 
> > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > > Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > r-b confirmed.
> > It's still fishy that we are implying an SMP effect where we need to
> > mandate the local processor order (that being the order evaluation of
> > request = *active; engine = *request; *active). The two *active are
> > already ordered across SMP, so we are only concered about this cpu. :|
> More second thoughts. rcu_assign_pointer(NULL) is not visible to
> rcu_access_pointer on another CPU without the smp_rmb. 

Should not a RCU read side lock be involved?

Is it not kind of the point that rcu_assign_pointer() will only be
visible everywhere when all previous read side critical sections have
ended after calling rcu_synchronize()? And will be valid during
rcu_read_lock().

If we do not use read side critical sections, how do we expect the
synchronization to happen by RCU code?

Regards, Joonas

> I think I am
> overestimating the barriers in place for RCU, and they are weaker than
> what I imagined for good reason.
> -Chris
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation