netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	a.p.zijlstra@chello.nl, cl@linux-foundation.org,
	Heiko Carstens <heiko.carstens@de.ibm.com>
Subject: Re: lockdep possible recursive lock in slab parent->list->rlock in rc2
Date: Mon, 28 Dec 2009 17:11:37 -0800	[thread overview]
Message-ID: <20091229011137.GA8469@linux.vnet.ibm.com> (raw)
In-Reply-To: <1261917194.5933.2.camel@penberg-laptop>

On Sun, Dec 27, 2009 at 02:33:14PM +0200, Pekka Enberg wrote:
> Hi Andi,
> 
> On Sun, 2009-12-27 at 13:06 +0100, Andi Kleen wrote:
> > Get this on a NFS root system while booting
> > This must be a recent change in the last week, 
> > I didn't see it in a post rc1 git* from last week
> > (I haven't done a exact bisect)
> > 
> > It's triggered by the r8169 driver close function, 
> > but looks more like a slab problem?
> > 
> > I haven't checked it in detail if the locks are 
> > really different or just lockdep not knowing 
> > enough classes.
> 
> I broke the lockdep annotations in commit
> ce79ddc8e2376a9a93c7d42daf89bfcbb9187e62 ("SLAB: Fix lockdep annotations
> for CPU hotplug"). Does this fix things for you? Heiko, the following
> patch should fix it for you too.

And no lockdep warnings here, either.  I did get the following
new-to-me preempt_count underflow, but doubt that it is related.

							Thanx, Paul

Badness at kernel/sched.c:5350
NIP: c0000000005b2e58 LR: c0000000005b2e3c CTR: c000000000025f0c
REGS: c000000042893b30 TRAP: 0700   Not tainted  (2.6.33-rc2-autokern1)
MSR: 8000000000029032 <EE,ME,CE,IR,DR>  CR: 22000082  XER: 0000000c
TASK = c00000007d8737e0[0] 'swapper' THREAD: c000000042890000 CPU: 2
GPR00: 0000000000000000 c000000042893db0 c0000000009c07f8 0000000000000001 
GPR04: 0000000000000001 0000000000000006 0000000000000001 000000000000004a 
GPR08: 0000000000000000 c00000000128adb8 c00000000088aa20 c000000000a0da08 
GPR12: 0000000000000002 c0000000009df880 0000000000000000 0000000000c00020 
GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000 
GPR20: 0000000000000000 c0000000009e24b0 0000000000000001 c0000000009df480 
GPR24: 0000000000000000 c0000000009d8628 c0000000009df880 0000000000000002 
GPR28: c0000000009e2068 c0000000009d8628 c00000000093c000 c000000042890000 
NIP [c0000000005b2e58] .sub_preempt_count+0x58/0xc8
LR [c0000000005b2e3c] .sub_preempt_count+0x3c/0xc8
Call Trace:
[c000000042893db0] [c000000042893e30] 0xc000000042893e30 (unreliable)
[c000000042893e30] [c000000000014d38] .cpu_idle+0x1f0/0x20c
[c000000042893ec0] [c0000000005ba678] .start_secondary+0x380/0x3c4
[c000000042893f90] [c000000000008264] .start_secondary_prolog+0x10/0x14
Instruction dump:
78290464 80090014 7f801800 40bc0074 4bd45745 60000000 2fa30000 419e0070 
e93e8a08 80090000 2f800000 409e0060 <0fe00000> 48000058 78000620 2fa00000 
BUG: scheduling while atomic: swapper/0/0x00000000
INFO: lockdep is turned off.
Modules linked in: ehea
Call Trace:
[c000000042897bf0] [c0000000000123b0] .show_stack+0x70/0x184 (unreliable)
[c000000042897ca0] [c00000000005eaa0] .__schedule_bug+0xa4/0xc4
[c000000042897d30] [c0000000005abe4c] .schedule+0xd8/0xa8c
[c000000042897e30] [c000000000014d40] .cpu_idle+0x1f8/0x20c
[c000000042897ec0] [c0000000005ba678] .start_secondary+0x380/0x3c4
[c000000042897f90] [c000000000008264] .start_secondary_prolog+0x10/0x14

> diff --git a/mm/slab.c b/mm/slab.c
> index 7d41f15..7451bda 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -654,7 +654,7 @@ static void init_node_lock_keys(int q)
> 
>  		l3 = s->cs_cachep->nodelists[q];
>  		if (!l3 || OFF_SLAB(s->cs_cachep))
> -			return;
> +			continue;
>  		lockdep_set_class(&l3->list_lock, &on_slab_l3_key);
>  		alc = l3->alien;
>  		/*
> @@ -665,7 +665,7 @@ static void init_node_lock_keys(int q)
>  		 * for alloc_alien_cache,
>  		 */
>  		if (!alc || (unsigned long)alc == BAD_ALIEN_MAGIC)
> -			return;
> +			continue;
>  		for_each_node(r) {
>  			if (alc[r])
>  				lockdep_set_class(&alc[r]->lock,
> 
> 

      parent reply	other threads:[~2009-12-29  1:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-27 12:06 lockdep possible recursive lock in slab parent->list->rlock in rc2 Andi Kleen
2009-12-27 12:33 ` Pekka Enberg
2009-12-27 12:43   ` Andi Kleen
2009-12-28  9:40   ` Heiko Carstens
2009-12-29  1:11   ` Paul E. McKenney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091229011137.GA8469@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=cl@linux-foundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).