* Re: INFO: inconsistent lock state
@ 2006-07-09 22:30 Arne Ahrend
0 siblings, 0 replies; 6+ messages in thread
From: Arne Ahrend @ 2006-07-09 22:30 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: akpm, linux-kernel, marcel, maxk, mingo
On Sun, 2006-07-09 at 12:28 +0200, Arjan van de Ven wrote:
> I think this is a real bug, well in fact there seem to be 2:
>
> there are 2 locks that have dodgy locking, one is a spinlock one is a
> rwlock. Both are used in softirq context, but neither had the proper _bh
> marking. The patch below corrects this
The patch has been working very well so far, and the informational error message has
not resurfaced over a couple of restarts.
Many thanks!
Arne
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
^ permalink raw reply [flat|nested] 6+ messages in thread
* INFO: inconsistent lock state
@ 2010-09-13 14:51 Nils Radtke
2010-09-16 18:18 ` Maciej Rutecki
0 siblings, 1 reply; 6+ messages in thread
From: Nils Radtke @ 2010-09-13 14:51 UTC (permalink / raw)
To: Linux Kernel-Liste
Hi,
Got this in the logs:
PM: Adding info for No Bus:vcs7
PM: Adding info for No Bus:vcsa7
initialized framebuffer f62c8580 with backing bo f62c0080
=================================
[ INFO: inconsistent lock state ]
2.6.35.4 #11
---------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(&(&bdi->wb_lock)->rlock){+.?...}, at: [<c110b042>] bdi_queue_work+0x22/0x90
{SOFTIRQ-ON-W} state was registered at:
[<c10682f4>] __lock_acquire+0x984/0x17c0
[<c10691ab>] lock_acquire+0x7b/0x190
[<c16ecd81>] _raw_spin_lock+0x41/0x70
[<c10c7223>] bdi_task_init+0x23/0x70
[<c10c7a56>] bdi_forker_task+0x16/0x2e0
[<c1052b2c>] kthread+0x6c/0x80
[<c10031ba>] kernel_thread_helper+0x6/0x3c
irq event stamp: 523044
hardirqs last enabled at (523044): [<c10e2877>] kmem_cache_alloc_notrace+0x57/0xc0
hardirqs last disabled at (523043): [<c10e284f>] kmem_cache_alloc_notrace+0x2f/0xc0
softirqs last enabled at (522978): [<c103d305>] __do_softirq+0xe5/0x2e0
softirqs last disabled at (523039): [<c103d54d>] do_softirq+0x4d/0x60
other info that might help us debug this:
1 lock held by swapper/0:
#0: (&q->backing_dev_info.laptop_mode_wb_timer){+.-...}, at: [<c1044ddf>] run_timer_softirq+0xbf/0x500
stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.35.4 #11
Call Trace:
[<c16ea035>] ? printk+0x18/0x1a
[<c1065512>] print_usage_bug+0x162/0x1a0
[<c10658fb>] mark_lock+0x3ab/0x5b0
[<c10648bb>] ? trace_hardirqs_off+0xb/0x10
[<c1066180>] ? check_usage_forwards+0x0/0xe0
[<c10682b3>] __lock_acquire+0x943/0x17c0
[<c1004b1f>] ? dump_trace+0x7f/0xd0
[<c1064b7b>] ? save_trace+0x3b/0xc0
[<c106567c>] ? mark_lock+0x12c/0x5b0
[<c10648bb>] ? trace_hardirqs_off+0xb/0x10
[<c10691ab>] lock_acquire+0x7b/0x190
[<c110b042>] ? bdi_queue_work+0x22/0x90
[<c16ecd81>] _raw_spin_lock+0x41/0x70
[<c110b042>] ? bdi_queue_work+0x22/0x90
[<c110b042>] bdi_queue_work+0x22/0x90
[<c110b8de>] __bdi_start_writeback+0x7e/0x190
[<c110ba27>] bdi_start_writeback+0x17/0x20
[<c10badd8>] laptop_mode_timer_fn+0x38/0x50
[<c1044e67>] run_timer_softirq+0x147/0x500
[<c1044ddf>] ? run_timer_softirq+0xbf/0x500
[<c10bada0>] ? laptop_mode_timer_fn+0x0/0x50
[<c103d2a6>] __do_softirq+0x86/0x2e0
[<c103d54d>] do_softirq+0x4d/0x60
[<c103d725>] irq_exit+0x75/0x80
[<c1004453>] do_IRQ+0x43/0xb0
[<c10031ae>] common_interrupt+0x2e/0x34
[<c106007b>] ? time_to_tm+0x4b/0x1f0
[<c131fe74>] ? acpi_idle_enter_bm+0x21d/0x251
[<c14b67fa>] cpuidle_idle_call+0x6a/0x180
[<c1001bd9>] cpu_idle+0x39/0x70
[<c16de676>] rest_init+0xe6/0x100
[<c16de590>] ? rest_init+0x0/0x100
[<c1b6d823>] start_kernel+0x2f8/0x2fe
[<c1b6d355>] ? unknown_bootoption+0x0/0x1a0
[<c1b6d0b4>] i386_start_kernel+0xb4/0xbc
ata3.00: configured for UDMA/133
ata3: EH complete
sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
PM: Adding info for No Bus:vcs2
Cheers,
Nils
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: INFO: inconsistent lock state
2010-09-13 14:51 Nils Radtke
@ 2010-09-16 18:18 ` Maciej Rutecki
2010-09-17 18:05 ` Nils Radtke
0 siblings, 1 reply; 6+ messages in thread
From: Maciej Rutecki @ 2010-09-16 18:18 UTC (permalink / raw)
To: Nils Radtke; +Cc: Linux Kernel-Liste
On poniedziałek, 13 września 2010 o 16:51:02 Nils Radtke wrote:
> Hi,
>
> Got this in the logs:
>
> PM: Adding info for No Bus:vcs7
> PM: Adding info for No Bus:vcsa7
> initialized framebuffer f62c8580 with backing bo f62c0080
>
> =================================
> [ INFO: inconsistent lock state ]
> 2.6.35.4 #11
Older versions works OK? eg. 2.6.35 or 2.6.34?
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: INFO: inconsistent lock state
2010-09-16 18:18 ` Maciej Rutecki
@ 2010-09-17 18:05 ` Nils Radtke
0 siblings, 0 replies; 6+ messages in thread
From: Nils Radtke @ 2010-09-17 18:05 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: Linux Kernel-Liste
Hi,
That msg appeared on one of our notebooks, one which is very
prone to panic. Because of that I switched the lock checking
on for .35.4 . The machine tends to die of sucking the batts
empty while sleeping over night (that batt is ok..). Or it dies
when resuming from suspend or when using Xorg (submitted already
a bunch of reports on various issues, this beast is picky).
.35.4 is the first .35 running on this machine. Sorry, I just
checked, I only activated it for .35.4 . Config for .34 had
it still disabled.
Amongst others, those are now active:
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
Would you mind giving advice on which else debug parameter
to activate w/o performance loss (it's a productive work place)?
Cheers,
Nils
On Thu 2010-09-16 @ 08-18-16PM +0200, Maciej Rutecki wrote:
# On poniedziałek, 13 września 2010 o 16:51:02 Nils Radtke wrote:
# > Hi,
# >
# > Got this in the logs:
# >
# > PM: Adding info for No Bus:vcs7
# > PM: Adding info for No Bus:vcsa7
# > initialized framebuffer f62c8580 with backing bo f62c0080
# >
# > =================================
# > [ INFO: inconsistent lock state ]
# > 2.6.35.4 #11
#
# Older versions works OK? eg. 2.6.35 or 2.6.34?
#
# --
# Maciej Rutecki
# http://www.maciek.unixy.pl
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* INFO: inconsistent lock state
@ 2006-07-09 10:02 Arne Ahrend
2006-07-09 10:28 ` Arjan van de Ven
0 siblings, 1 reply; 6+ messages in thread
From: Arne Ahrend @ 2006-07-09 10:02 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel
On Sat, 2006-07-08 at 19:12 +0200, Arjan van de Ven wrote:
> Arne: Can you try this patch and verify it makes the message go away?
> [...]
> --- linux-2.6.17-mm6.orig/include/linux/skbuff.h
> +++ linux-2.6.17-mm6/include/linux/skbuff.h
> @@ -609,7 +609,6 @@ extern struct lock_class_key skb_queue_l
> static inline void skb_queue_head_init(struct sk_buff_head *list)
> {
> spin_lock_init(&list->lock);
> - lockdep_set_class(&list->lock, &skb_queue_lock_key);
> list->prev = list->next = (struct sk_buff *)list;
> list->qlen = 0;
> }
With this patch the message at boot goes away. However, I have had one
instance of the following message at shutdown, but not always.
This particular one happened with the above patch applied.
Arne
[ INFO: inconsistent lock state ]
---------------------------------
inconsistent {in-softirq-W} -> {softirq-on-W} usage.
kbnepd bnep0/2098 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&conn->lock){-+..}, at: [<e29dea5f>] __l2cap_sock_close+0xb9/0x111 [l2cap]
{in-softirq-W} state was registered at:
[<c012a05e>] lock_acquire+0x4f/0x6d
[<c0265e61>] _spin_lock+0x24/0x32
[<e29df9f6>] l2cap_connect_cfm+0x8d/0x12a [l2cap]
[<e2921d6b>] hci_event_packet+0x65e/0xddb [bluetooth]
[<e291f279>] hci_rx_task+0x77/0x22f [bluetooth]
[<c011786f>] tasklet_action+0x45/0x75
[<c0117a76>] __do_softirq+0x45/0x9f
[<c010480e>] do_softirq+0x4d/0xab
irq event stamp: 208973
hardirqs last enabled at (208973): [<c02661f0>] _spin_unlock_irqrestore+0x36/0x55
hardirqs last disabled at (208972): [<c0265c4b>] _spin_lock_irqsave+0xf/0x3c
softirqs last enabled at (208970): [<c021367d>] lock_sock+0xad/0xb8
softirqs last disabled at (208968): [<c0265cbb>] _spin_lock_bh+0xb/0x37
other info that might help us debug this:
2 locks held by kbnepd bnep0/2098:
#0: (bnep_session_sem){----}, at: [<e29e59b6>] bnep_session+0x67b/0x6b5 [bnep]
#1: (sk_lock-AF_BLUETOOTH){--..}, at: [<e29dff7b>] l2cap_sock_shutdown+0x18/0x6b [l2cap]
stack backtrace:
[<c0103433>] show_trace+0x16/0x19
[<c0103913>] dump_stack+0x1a/0x1f
[<c01284b8>] print_usage_bug+0x1d0/0x1da
[<c0128a62>] mark_lock+0x23c/0x35a
[<c01295f7>] __lock_acquire+0x41b/0x929
[<c012a05e>] lock_acquire+0x4f/0x6d
[<c0265e61>] _spin_lock+0x24/0x32
[<e29dea5f>] __l2cap_sock_close+0xb9/0x111 [l2cap]
[<e29dff98>] l2cap_sock_shutdown+0x35/0x6b [l2cap]
[<e29e00a2>] l2cap_sock_release+0x20/0x5f [l2cap]
[<c02120b9>] sock_release+0x16/0xab
[<c02123de>] sock_close+0x30/0x3a
[<c014ec5d>] __fput+0xa8/0x18a
[<c014ee08>] fput+0x2e/0x33
[<e29e59cc>] bnep_session+0x691/0x6b5 [bnep]
[<c01006e9>] kernel_thread_helper+0x5/0xb
__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: INFO: inconsistent lock state
2006-07-09 10:02 Arne Ahrend
@ 2006-07-09 10:28 ` Arjan van de Ven
0 siblings, 0 replies; 6+ messages in thread
From: Arjan van de Ven @ 2006-07-09 10:28 UTC (permalink / raw)
To: Arne Ahrend; +Cc: marcel, maxk, akpm, mingo, linux-kernel
On Sun, 2006-07-09 at 12:02 +0200, Arne Ahrend wrote:
> On Sat, 2006-07-08 at 19:12 +0200, Arjan van de Ven wrote:
> > Arne: Can you try this patch and verify it makes the message go away?
> > [...]
> > --- linux-2.6.17-mm6.orig/include/linux/skbuff.h
> > +++ linux-2.6.17-mm6/include/linux/skbuff.h
> > @@ -609,7 +609,6 @@ extern struct lock_class_key skb_queue_l
> > static inline void skb_queue_head_init(struct sk_buff_head *list)
> > {
> > spin_lock_init(&list->lock);
> > - lockdep_set_class(&list->lock, &skb_queue_lock_key);
> > list->prev = list->next = (struct sk_buff *)list;
> > list->qlen = 0;
> > }
>
> With this patch the message at boot goes away. However, I have had one
> instance of the following message at shutdown, but not always.
> This particular one happened with the above patch applied.
>
I think this is a real bug, well in fact there seem to be 2:
there are 2 locks that have dodgy locking, one is a spinlock one is a
rwlock. Both are used in softirq context, but neither had the proper _bh
marking. The patch below corrects this
---
net/bluetooth/l2cap.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
Index: linux-2.6.17-mm6/net/bluetooth/l2cap.c
===================================================================
--- linux-2.6.17-mm6.orig/net/bluetooth/l2cap.c
+++ linux-2.6.17-mm6/net/bluetooth/l2cap.c
@@ -167,9 +167,9 @@ static int l2cap_conn_del(struct hci_con
static inline void l2cap_chan_add(struct l2cap_conn *conn, struct sock *sk, struct sock *parent)
{
struct l2cap_chan_list *l = &conn->chan_list;
- write_lock(&l->lock);
+ write_lock_bh(&l->lock);
__l2cap_chan_add(conn, sk, parent);
- write_unlock(&l->lock);
+ write_unlock_bh(&l->lock);
}
static inline u8 l2cap_get_ident(struct l2cap_conn *conn)
@@ -182,14 +182,14 @@ static inline u8 l2cap_get_ident(struct
* 200 - 254 are used by utilities like l2ping, etc.
*/
- spin_lock(&conn->lock);
+ spin_lock_bh(&conn->lock);
if (++conn->tx_ident > 128)
conn->tx_ident = 1;
id = conn->tx_ident;
- spin_unlock(&conn->lock);
+ spin_unlock_bh(&conn->lock);
return id;
}
@@ -1006,7 +1006,7 @@ static inline void l2cap_chan_unlink(str
{
struct sock *next = l2cap_pi(sk)->next_c, *prev = l2cap_pi(sk)->prev_c;
- write_lock(&l->lock);
+ write_lock_bh(&l->lock);
if (sk == l->head)
l->head = next;
@@ -1014,7 +1014,7 @@ static inline void l2cap_chan_unlink(str
l2cap_pi(next)->prev_c = prev;
if (prev)
l2cap_pi(prev)->next_c = next;
- write_unlock(&l->lock);
+ write_unlock_bh(&l->lock);
__sock_put(sk);
}
@@ -1424,7 +1424,7 @@ static inline int l2cap_connect_req(stru
if (!sk)
goto response;
- write_lock(&list->lock);
+ write_lock_bh(&list->lock);
/* Check if we already have channel with that dcid */
if (__l2cap_get_chan_by_dcid(list, scid)) {
@@ -1466,7 +1466,7 @@ static inline int l2cap_connect_req(stru
result = status = 0;
done:
- write_unlock(&list->lock);
+ write_unlock_bh(&list->lock);
response:
bh_unlock_sock(parent);
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-09-17 18:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-09 22:30 INFO: inconsistent lock state Arne Ahrend
-- strict thread matches above, loose matches on Subject: below --
2010-09-13 14:51 Nils Radtke
2010-09-16 18:18 ` Maciej Rutecki
2010-09-17 18:05 ` Nils Radtke
2006-07-09 10:02 Arne Ahrend
2006-07-09 10:28 ` Arjan van de Ven
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox