lkml.org 
[lkml]   [2009]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tip:core/rcu] rcu: Consolidate sparse and lockdep declarations in include/linux/rcupdate.h
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


\
 
 \ /
  Last update: 2009-08-24 00:57    [W:0.850 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site