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@xxxxxxxxxxxxxxxxxx> > > > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
