From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [Bug 16617] New: inconsistent lock state at boot Date: Mon, 23 Aug 2010 21:25:07 +0200 Message-ID: <1282591507.2378.147.camel@edumazet-laptop> References: <20100823121837.e246fb69.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: netdev@vger.kernel.org, bugzilla-daemon@bugzilla.kernel.org, Patrick McHardy , casteyde.christian@free.fr To: Andrew Morton Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:49535 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751690Ab0HWTZM (ORCPT ); Mon, 23 Aug 2010 15:25:12 -0400 Received: by wyb32 with SMTP id 32so7152851wyb.19 for ; Mon, 23 Aug 2010 12:25:11 -0700 (PDT) In-Reply-To: <20100823121837.e246fb69.akpm@linux-foundation.org> Sender: netdev-owner@vger.kernel.org List-ID: Le lundi 23 ao=C3=BBt 2010 =C3=A0 12:18 -0700, Andrew Morton a =C3=A9cr= it : > (switched to email. Please respond via emailed reply-to-all, not via= the > bugzilla web interface). >=20 > On Tue, 17 Aug 2010 20:05:55 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: >=20 > > https://bugzilla.kernel.org/show_bug.cgi?id=3D16617 > >=20 > > Summary: inconsistent lock state at boot > > Product: Memory Management > > Version: 2.5 > > Kernel Version: 2.6.36-rc1 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: akpm@linux-foundation.org > > ReportedBy: casteyde.christian@free.fr > > Regression: Yes > >=20 > >=20 > > Kernel 2.6.36-rc1 > > Athlon64 X2 4200 in 64bit mode > > Slackware64 13.1 > > 1 GB RAM > >=20 > > Since 2.6.36-rc1 with debug options activated (lock validation, kme= mcheck, > > etc.), I get the following error at boot: > >=20 > > ADDRCONF(NETDEV_UP): eth0: link is not ready > > uli526x: eth0 NIC Link is Up 100 Mbps Full duplex > > ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > [ INFO: inconsistent lock state ] > > 2.6.36-rc1 #2 > > --------------------------------- > > inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. > > iptables/1915 [HC0[0]:SC0[0]:HE1:SE1] takes: > > (&(&lock->lock)->rlock){+.?...}, at: [] > > get_counters+0x111/0x1c0 > > {IN-SOFTIRQ-W} state was registered at: > > [] __lock_acquire+0xb96/0x1c10 > > [] lock_acquire+0x5a/0x70 > > [] _raw_spin_lock+0x36/0x50 > > [] ip6t_do_table+0x88/0x4e0 > > [] ip6table_filter_hook+0x17/0x20 > > [] nf_iterate+0x64/0xa0 > > [] nf_hook_slow+0xa4/0x150 > > [] mld_sendpack+0x28b/0x4d0 > > [] mld_ifc_timer_expire+0x27b/0x310 > > [] run_timer_softirq+0x1ae/0x2e0 > > [] __do_softirq+0xc0/0x160 > > [] call_softirq+0x1c/0x30 > > [] do_softirq+0x75/0xb0 > > [] irq_exit+0x95/0xa0 > > [] smp_apic_timer_interrupt+0x6a/0xa0 > > [] apic_timer_interrupt+0x13/0x20 > > [] ext4_lookup+0x9d/0x110 > > [] do_lookup+0x1db/0x270 > > [] link_path_walk+0x445/0xbe0 > > [] path_walk+0x60/0xe0 > > [] do_path_lookup+0x53/0x60 > > [] user_path_at+0x53/0xa0 > > [] vfs_fstatat+0x37/0x70 > > [] vfs_stat+0x16/0x20 > > [] sys_newstat+0x1f/0x50 > > [] system_call_fastpath+0x16/0x1b > > irq event stamp: 73961 > > hardirqs last enabled at (73961): [] > > local_bh_enable+0x7e/0x100 > > hardirqs last disabled at (73959): [] > > local_bh_enable+0x31/0x100 > > softirqs last enabled at (73960): [] get_counter= s+0x7b/0x1c0 > > softirqs last disabled at (73914): [] get_counter= s+0x2e/0x1c0 > >=20 > > other info that might help us debug this: > > 2 locks held by iptables/1915: > > #0: (sk_lock-AF_INET){+.+.+.}, at: [] > > ip_getsockopt+0x6a/0xb0 > > #1: (&xt[i].mutex){+.+.+.}, at: [] > > xt_find_table_lock+0x3e/0x120 > >=20 > > stack backtrace: > > Pid: 1915, comm: iptables Not tainted 2.6.36-rc1 #2 > > Call Trace: > > [] print_usage_bug+0x181/0x1d0 > > [] mark_lock+0x419/0x630 > > [] __lock_acquire+0xc0c/0x1c10 > > [] ? trace_hardirqs_off_thunk+0x3a/0x3c > > [] ? trace_hardirqs_off_thunk+0x3a/0x3c > > [] ? trace_hardirqs_off_thunk+0x3a/0x3c > > [] lock_acquire+0x5a/0x70 > > [] ? get_counters+0x111/0x1c0 > > [] ? trace_hardirqs_on_caller+0x13d/0x180 > > [] _raw_spin_lock+0x36/0x50 > > [] ? get_counters+0x111/0x1c0 > > [] ? local_bh_enable+0x7e/0x100 > > [] get_counters+0x111/0x1c0 > > [] alloc_counters+0x2e/0x50 > > [] ? do_ipt_get_ctl+0xfd/0x3a0 > > [] do_ipt_get_ctl+0x1e1/0x3a0 > > [] ? trace_hardirqs_on+0xd/0x10 > > [] nf_sockopt+0x90/0xa0 > > [] nf_getsockopt+0x13/0x20 > > [] ip_getsockopt+0x80/0xb0 > > [] raw_getsockopt+0x11/0x30 > > [] sock_common_getsockopt+0xf/0x20 > > [] sys_getsockopt+0x60/0xc0 > > [] system_call_fastpath+0x16/0x1b > >=20 > > I haven't managed to find the faulty module. > >=20 Already fixed in Linus tree commit 001389b9581c13fe5fc357a0f89234f85af4215d Author: Eric Dumazet Date: Mon Aug 16 10:22:10 2010 +0000 netfilter: {ip,ip6,arp}_tables: avoid lockdep false positive =20 After commit 24b36f019 (netfilter: {ip,ip6,arp}_tables: dont block bottom half more than necessary), lockdep can raise a warning because we attempt to lock a spinlock with BH enabled, while the same lock is usually locked by another cpu in a softirq context= =2E =20 Disable again BH to avoid these lockdep warnings. =20 Reported-by: Linus Torvalds Diagnosed-by: David S. Miller Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller