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,
>
>
prev 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.