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 <ch...@chris-wilson.co.uk> > > > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > > > Reviewed-by: Daniel Vetter <daniel.vet...@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. I think I am overestimating the barriers in place for RCU, and they are weaker than what I imagined for good reason. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
