Re: [tip:core/rcu] rcu: Consolidate sparse and lockdep declarations in include/linux/rcupdate.h

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

On Sun, Aug 23, 2009 at 12:33:56PM -0700, Paul E. McKenney wrote:
> On Sun, Aug 23, 2009 at 08:42:02PM +0200, Ingo Molnar wrote:
> > 
> > * tip-bot for Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > 
> > > Commit-ID:  bc33f24bdca8b6e97376e3a182ab69e6cdefa989
> > > Gitweb:     http://git.kernel.org/tip/bc33f24bdca8b6e97376e3a182ab69e6cdefa989
> > > Author:     Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > > AuthorDate: Sat, 22 Aug 2009 13:56:47 -0700
> > > Committer:  Ingo Molnar <mingo@elte.hu>
> > > CommitDate: Sun, 23 Aug 2009 10:32:37 +0200
> > > 
> > > rcu: Consolidate sparse and lockdep declarations in include/linux/rcupdate.h
> > 
> > -tip testing found a spontaneous reboot crash, which i 
> > bisected back to this commit:
> > 
> >   bc33f24bdca8b6e97376e3a182ab69e6cdefa989 is first bad commit
> > 
> > the reboot happens during the ftrace syscall tracepoints 
> > self-test:
> > 
> > [   34.618832] Testing event sys_exit_set_robust_list: OK
> > [   34.635511] Testing event sys_enter_get_robust_list: OK
> > [   34.652164] Testing event sys_exit_get_robust_list: OK
> > [   34.668844] Testing event sys_enter_futex: OK
> > [   34.685495] Testing event sys_exit_futex: OK
> > [   34.702170] Testing event lock_acquire: [instant reboot]
> > 
> > There's no log message - just a reboot - which signals some 
> > severe crash - perhaps some locking related infinite 
> > recursion or something like that?
> 
> Pretty impressive for having mostly moved RCU's lockdep-related
> declarations from one file to another...  :-/
> 
> Looking into it, probably a typo on my part.

I rechecked this several times, and don't see how anything else should
have noticed this patch.  That said, that self-test is rather amazing
code, so...

For the moment, I will simply drop bc33f24bdca8 from my stack.  For one
thing, once CONFIG_PREEMPT_RCU is dropped, there is much less advantage
to consolidating these annotations.

But I do have one stupid question...  Given that rcu_read_lock() cannot
participate in deadlock cycles, why is lockdep tracking it?

In any case, I will send a new stack in a day or so (currently testing)
that drops bc33f24bdca8 and adds some changes that make CPU hotplug work
much better for CONFIG_TREE_PREEMPT_RCU.

							Thanx, Paul