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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux