lkml.org 
[lkml]   [2011]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: call_function_many: fix list delete vs add race
From
Date
On Mon, 31 Jan 2011 about 11:27:45 +0100, Peter Zijlstra wrote: 
> On Fri, 2011-01-28 at 18:20 -0600, Milton Miller wrote:
> > Peter pointed out there was nothing preventing the list_del_rcu in
> > smp_call_function_interrupt from running before the list_add_rcu in
> > smp_call_function_many. Fix this by not setting refs until we have put
> > the entry on the list. We can use the lock acquire and release instead
> > of a wmb.
> >
> > Reported-by: Peter Zijlstra <peterz@infradead.org>
> > Signed-off-by: Milton Miller <miltonm@bga.com>
> > Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > ---
> >
> > I tried to force this race with a udelay before the lock & list_add and
> > by mixing all 64 online cpus with just 3 random cpus in the mask, but
> > was unsuccessful. Still, it seems to be a valid race, and the fix
> > is a simple change to the current code.
>
> Yes, I think this will fix it, I think simply putting that assignment
> under the lock is sufficient, because then the list removal will
> serialize again the list add. But placing it after the list add does
> also seem sufficient.
>
> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>

I was worried some architectures would allow a write before the spinlock
to drop into the spinlock region, in which case the data or function
pointer could be found stale with the cpu mask bit set. The unlock
must flush all prior writes and therefore the new function and data
will be seen before refs is set.

milton


\
 
 \ /
  Last update: 2011-01-31 21:29    [W:0.151 / U:0.164 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site