Re: [PATCH,RFC] Add call_rcu_sched()

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Tue, Apr 08, 2008 at 02:07:58AM -0700, Andrew Morton wrote:
> On Tue, 8 Apr 2008 14:26:37 +0530 Gautham R Shenoy <ego@in.ibm.com> wrote:
> 
> > On Tue, Apr 08, 2008 at 01:39:36AM -0700, Andrew Morton wrote:
> > > On Tue, 8 Apr 2008 13:40:48 +0530 Gautham R Shenoy <ego@in.ibm.com> wrote:
> > > 
> > > > > > +			rdp = RCU_DATA_CPU(cpu);
> > > >                                                                <-- here ------\
> > > > > > +			spin_lock_irqsave(&rdp->lock, flags);                   |
> > > > > > +                                                                         |
> > > > > > +			/*                                                      |
> > > > > > +			 * We are running on this CPU irq-disabled, so no       |
> > > > > > +			 * CPU can go offline until we re-enable irqs.          |
> > > > >                                                                             |
> > > > > but, but, but.  The cpu at `cpu' could have gone offline just before we     |
> > > > > disabled local interrupts.                                                  |
> > > >                                                                               |
> > > > In that case the CPU_DEAD callback should have migrated the rcu-lists to      |
> > > > a cpu which is online.                                                        |
> > >                                                                                 |
> > > But local variable rdp might be pointing at the now-offlined CPU's data? -------/
> > 
> > Right. But then rdp wouldn't contain anything useful at this point.
> > So, we may only end up taking the rdp->lock, observe that there's nothing to do,
> > and move on.
> > 
> > Is there something else that I am missing?
> 
> erm, I guess that'll work OK.
> 
> There were intentions to release the per-cpu memory during unplug, but
> nobody has threatened to do that for a while.

That would be a bit painful in a number of situations...  :-/

							Thanx, Paul