From: Jarek Poplawski <jarkao2@o2.pl>
To: "Yuriy N. Shkandybin" <jura@netams.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
netdev@vger.kernel.org,
"bugme-daemon@kernel-bugs.osdl.org"
<bugme-daemon@bugzilla.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-ppp@vger.kernel.org, Paul Mackerras <paulus@samba.org>
Subject: [PATCH] ppp_generic: lockdep warning Re: [Bug 8132] New: pptp server lockup ...
Date: Wed, 28 Mar 2007 08:19:55 +0000 [thread overview]
Message-ID: <20070328081955.GA2363@ff.dom.local> (raw)
In-Reply-To: <03ac01c769fb$16bc5ea0$9b01a8c0@Jura>
On Mon, Mar 19, 2007 at 10:49:12AM +0300, Yuriy N. Shkandybin wrote:
> I've changed kernel to rc4 and completely changed hardware.
> Now this is
>
> I've got new trace, but this is another problem as i can see and connected
> with pppoe
>
> ===========================> [ INFO: possible circular locking dependency detected ]
> 2.6.21-rc4 #1
> -------------------------------------------------------
> pppd/8926 is trying to acquire lock:
> (&vlan_netdev_xmit_lock_key){-...}, at: [<c0265486>]
> dev_queue_xmit+0x247/0x2f1
>
> but task is already holding lock:
> (&pch->downl){-+..}, at: [<c0230c72>] ppp_channel_push+0x19/0x9a
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (&pch->downl){-+..}:
> [<c013642b>] __lock_acquire+0xe62/0x1010
> [<c0136642>] lock_acquire+0x69/0x83
> [<c02afc13>] _spin_lock_bh+0x30/0x3d
> [<c022f715>] ppp_push+0x5a/0x9a
> [<c022fb40>] ppp_xmit_process+0x2e/0x511
> [<c0231a05>] ppp_write+0xb8/0xf2
> [<c015ec26>] vfs_write+0x7f/0xba
> [<c015f158>] sys_write+0x3d/0x64
> [<c01027de>] sysenter_past_esp+0x5f/0x99
> [<ffffffff>] 0xffffffff
>
> -> #2 (&ppp->wlock){-+..}:
> [<c013642b>] __lock_acquire+0xe62/0x1010
> [<c0136642>] lock_acquire+0x69/0x83
> [<c02afc13>] _spin_lock_bh+0x30/0x3d
> [<c022fb2b>] ppp_xmit_process+0x19/0x511
> [<c02318d3>] ppp_start_xmit+0x18a/0x204
> [<c0263a6f>] dev_hard_start_xmit+0x1f6/0x2c4
> [<c026ded3>] __qdisc_run+0x81/0x1bc
> [<c026549e>] dev_queue_xmit+0x25f/0x2f1
> [<c027c75f>] ip_output+0x1be/0x25f
> [<c02788ce>] ip_forward+0x159/0x22b
> [<c027745c>] ip_rcv+0x297/0x4dd
> [<c0263698>] netif_receive_skb+0x164/0x1f2
> [<c022199d>] e1000_clean_rx_irq+0x12a/0x4b7
> [<c02209bc>] e1000_clean+0x3ff/0x5dd
> [<c0265084>] net_rx_action+0x7d/0x12b
> [<c011e442>] __do_softirq+0x82/0xf2
> [<c011e509>] do_softirq+0x57/0x59
> [<c011e877>] irq_exit+0x7f/0x81
> [<c0105011>] do_IRQ+0x45/0x84
> [<c0103252>] common_interrupt+0x2e/0x34
> [<c0100b66>] mwait_idle+0x12/0x14
> [<c0100c60>] cpu_idle+0x6c/0x86
> [<c01001cd>] rest_init+0x23/0x36
> [<c0377d89>] start_kernel+0x3ca/0x461
> [<00000000>] 0x0
> [<ffffffff>] 0xffffffff
>
> -> #1 (&dev->_xmit_lock){-+..}:
> [<c013642b>] __lock_acquire+0xe62/0x1010
> [<c0136642>] lock_acquire+0x69/0x83
> [<c02afc13>] _spin_lock_bh+0x30/0x3d
> [<c0266861>] dev_mc_add+0x34/0x16a
> [<c02ab5c7>] vlan_dev_set_multicast_list+0x88/0x25c
> [<c0266592>] __dev_mc_upload+0x22/0x24
> [<c0266914>] dev_mc_add+0xe7/0x16a
> [<c029f323>] igmp_group_added+0xe6/0xeb
> [<c029f50b>] ip_mc_inc_group+0x13f/0x210
> [<c029f5fa>] ip_mc_up+0x1e/0x61
> [<c029ab81>] inetdev_event+0x154/0x2c7
> [<c0125a46>] notifier_call_chain+0x2c/0x39
> [<c0125a7c>] raw_notifier_call_chain+0x8/0xa
> [<c026477a>] dev_open+0x6d/0x71
> [<c0263028>] dev_change_flags+0x51/0x101
> [<c029b7ca>] devinet_ioctl+0x4df/0x644
> [<c029bc03>] inet_ioctl+0x5c/0x6f
> [<c02596e0>] sock_ioctl+0x4f/0x1e8
> [<c0168c32>] do_ioctl+0x22/0x71
> [<c0168cd6>] vfs_ioctl+0x55/0x27e
> [<c0168f32>] sys_ioctl+0x33/0x51
> [<c01027de>] sysenter_past_esp+0x5f/0x99
> [<ffffffff>] 0xffffffff
>
> -> #0 (&vlan_netdev_xmit_lock_key){-...}:
> [<c0136289>] __lock_acquire+0xcc0/0x1010
> [<c0136642>] lock_acquire+0x69/0x83
> [<c02afbd6>] _spin_lock+0x2b/0x38
> [<c0265486>] dev_queue_xmit+0x247/0x2f1
> [<c02334f6>] __pppoe_xmit+0x1a9/0x215
> [<c023356c>] pppoe_xmit+0xa/0xc
> [<c0230c9a>] ppp_channel_push+0x41/0x9a
> [<c0231a13>] ppp_write+0xc6/0xf2
> [<c015ec26>] vfs_write+0x7f/0xba
> [<c015f158>] sys_write+0x3d/0x64
> [<c01027de>] sysenter_past_esp+0x5f/0x99
> [<ffffffff>] 0xffffffff
>
> other info that might help us debug this:
>
> 1 lock held by pppd/8926:
> #0: (&pch->downl){-+..}, at: [<c0230c72>] ppp_channel_push+0x19/0x9a
>
> stack backtrace:
> [<c0103834>] show_trace_log_lvl+0x1a/0x30
> [<c0103f16>] show_trace+0x12/0x14
> [<c0103f9d>] dump_stack+0x16/0x18
> [<c01343cd>] print_circular_bug_tail+0x68/0x71
> [<c0136289>] __lock_acquire+0xcc0/0x1010
> [<c0136642>] lock_acquire+0x69/0x83
> [<c02afbd6>] _spin_lock+0x2b/0x38
> [<c0265486>] dev_queue_xmit+0x247/0x2f1
> [<c02334f6>] __pppoe_xmit+0x1a9/0x215
> [<c023356c>] pppoe_xmit+0xa/0xc
> [<c0230c9a>] ppp_channel_push+0x41/0x9a
> [<c0231a13>] ppp_write+0xc6/0xf2
> [<c015ec26>] vfs_write+0x7f/0xba
> [<c015f158>] sys_write+0x3d/0x64
> [<c01027de>] sysenter_past_esp+0x5f/0x99
> ===========> Clocksource tsc unstable (delta = 4686844667 ns)
> Time: acpi_pm clocksource has been installed.
...
lockdep has seen locks "-> #0" - "-> #3" taken in circular
order, but IMHO, lock "-> #3" (&pch->downl) taken after
"-> #2" (&ppp->wlock) differs from &pch->downl lock taken in
"-> #0" (before &vlan_netdev_xmit_lock_key) and lockdep
should be notified about this.
This patch proposal needs confirmation by some PPP expert
that channels processed in ppp_channel_push() differ from
channels processed in ppp_xmit_process(), so the same channel
cannot be processed by turns with both these functions.
I also hope Yuriy could test this patch (this should apply to
2.6.21-rc4 or later, CONFIG_PROVE_LOCKING = y), thanks.
Reported & tested by: "Yuriy N. Shkandybin" <jura@netams.com>
Signed-off-by: Jarek Poplawski <jarkao2@o2.pl>
(don't apply without above mentioned acks)
---
diff -Nurp 2.6.21-rc5-git1-/drivers/net/ppp_generic.c 2.6.21-rc5-git1/drivers/net/ppp_generic.c
--- 2.6.21-rc5-git1-/drivers/net/ppp_generic.c 2007-03-27 20:24:30.000000000 +0200
+++ 2.6.21-rc5-git1/drivers/net/ppp_generic.c 2007-03-27 20:34:44.000000000 +0200
@@ -1435,7 +1435,8 @@ ppp_channel_push(struct channel *pch)
struct sk_buff *skb;
struct ppp *ppp;
- spin_lock_bh(&pch->downl);
+ local_bh_disable();
+ spin_lock_nested(&pch->downl, SINGLE_DEPTH_NESTING);
if (pch->chan != 0) {
while (!skb_queue_empty(&pch->file.xq)) {
skb = skb_dequeue(&pch->file.xq);
@@ -1449,7 +1450,8 @@ ppp_channel_push(struct channel *pch)
/* channel got deregistered */
skb_queue_purge(&pch->file.xq);
}
- spin_unlock_bh(&pch->downl);
+ spin_unlock(&pch->downl);
+ local_bh_enable();
/* see if there is anything from the attached unit to be sent */
if (skb_queue_empty(&pch->file.xq)) {
read_lock_bh(&pch->upl);
WARNING: multiple messages have this Message-ID (diff)
From: Jarek Poplawski <jarkao2@o2.pl>
To: "Yuriy N\. Shkandybin" <jura@netams.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
netdev@vger.kernel.org,
"bugme-daemon\@kernel-bugs\.osdl\.org"
<bugme-daemon@bugzilla.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-ppp@vger.kernel.org, Paul Mackerras <paulus@samba.org>
Subject: [PATCH] ppp_generic: lockdep warning Re: [Bug 8132] New: pptp server lockup ...
Date: Wed, 28 Mar 2007 10:19:55 +0200 [thread overview]
Message-ID: <20070328081955.GA2363@ff.dom.local> (raw)
In-Reply-To: <03ac01c769fb$16bc5ea0$9b01a8c0@Jura>
On Mon, Mar 19, 2007 at 10:49:12AM +0300, Yuriy N. Shkandybin wrote:
> I've changed kernel to rc4 and completely changed hardware.
> Now this is
>
> I've got new trace, but this is another problem as i can see and connected
> with pppoe
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.21-rc4 #1
> -------------------------------------------------------
> pppd/8926 is trying to acquire lock:
> (&vlan_netdev_xmit_lock_key){-...}, at: [<c0265486>]
> dev_queue_xmit+0x247/0x2f1
>
> but task is already holding lock:
> (&pch->downl){-+..}, at: [<c0230c72>] ppp_channel_push+0x19/0x9a
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (&pch->downl){-+..}:
> [<c013642b>] __lock_acquire+0xe62/0x1010
> [<c0136642>] lock_acquire+0x69/0x83
> [<c02afc13>] _spin_lock_bh+0x30/0x3d
> [<c022f715>] ppp_push+0x5a/0x9a
> [<c022fb40>] ppp_xmit_process+0x2e/0x511
> [<c0231a05>] ppp_write+0xb8/0xf2
> [<c015ec26>] vfs_write+0x7f/0xba
> [<c015f158>] sys_write+0x3d/0x64
> [<c01027de>] sysenter_past_esp+0x5f/0x99
> [<ffffffff>] 0xffffffff
>
> -> #2 (&ppp->wlock){-+..}:
> [<c013642b>] __lock_acquire+0xe62/0x1010
> [<c0136642>] lock_acquire+0x69/0x83
> [<c02afc13>] _spin_lock_bh+0x30/0x3d
> [<c022fb2b>] ppp_xmit_process+0x19/0x511
> [<c02318d3>] ppp_start_xmit+0x18a/0x204
> [<c0263a6f>] dev_hard_start_xmit+0x1f6/0x2c4
> [<c026ded3>] __qdisc_run+0x81/0x1bc
> [<c026549e>] dev_queue_xmit+0x25f/0x2f1
> [<c027c75f>] ip_output+0x1be/0x25f
> [<c02788ce>] ip_forward+0x159/0x22b
> [<c027745c>] ip_rcv+0x297/0x4dd
> [<c0263698>] netif_receive_skb+0x164/0x1f2
> [<c022199d>] e1000_clean_rx_irq+0x12a/0x4b7
> [<c02209bc>] e1000_clean+0x3ff/0x5dd
> [<c0265084>] net_rx_action+0x7d/0x12b
> [<c011e442>] __do_softirq+0x82/0xf2
> [<c011e509>] do_softirq+0x57/0x59
> [<c011e877>] irq_exit+0x7f/0x81
> [<c0105011>] do_IRQ+0x45/0x84
> [<c0103252>] common_interrupt+0x2e/0x34
> [<c0100b66>] mwait_idle+0x12/0x14
> [<c0100c60>] cpu_idle+0x6c/0x86
> [<c01001cd>] rest_init+0x23/0x36
> [<c0377d89>] start_kernel+0x3ca/0x461
> [<00000000>] 0x0
> [<ffffffff>] 0xffffffff
>
> -> #1 (&dev->_xmit_lock){-+..}:
> [<c013642b>] __lock_acquire+0xe62/0x1010
> [<c0136642>] lock_acquire+0x69/0x83
> [<c02afc13>] _spin_lock_bh+0x30/0x3d
> [<c0266861>] dev_mc_add+0x34/0x16a
> [<c02ab5c7>] vlan_dev_set_multicast_list+0x88/0x25c
> [<c0266592>] __dev_mc_upload+0x22/0x24
> [<c0266914>] dev_mc_add+0xe7/0x16a
> [<c029f323>] igmp_group_added+0xe6/0xeb
> [<c029f50b>] ip_mc_inc_group+0x13f/0x210
> [<c029f5fa>] ip_mc_up+0x1e/0x61
> [<c029ab81>] inetdev_event+0x154/0x2c7
> [<c0125a46>] notifier_call_chain+0x2c/0x39
> [<c0125a7c>] raw_notifier_call_chain+0x8/0xa
> [<c026477a>] dev_open+0x6d/0x71
> [<c0263028>] dev_change_flags+0x51/0x101
> [<c029b7ca>] devinet_ioctl+0x4df/0x644
> [<c029bc03>] inet_ioctl+0x5c/0x6f
> [<c02596e0>] sock_ioctl+0x4f/0x1e8
> [<c0168c32>] do_ioctl+0x22/0x71
> [<c0168cd6>] vfs_ioctl+0x55/0x27e
> [<c0168f32>] sys_ioctl+0x33/0x51
> [<c01027de>] sysenter_past_esp+0x5f/0x99
> [<ffffffff>] 0xffffffff
>
> -> #0 (&vlan_netdev_xmit_lock_key){-...}:
> [<c0136289>] __lock_acquire+0xcc0/0x1010
> [<c0136642>] lock_acquire+0x69/0x83
> [<c02afbd6>] _spin_lock+0x2b/0x38
> [<c0265486>] dev_queue_xmit+0x247/0x2f1
> [<c02334f6>] __pppoe_xmit+0x1a9/0x215
> [<c023356c>] pppoe_xmit+0xa/0xc
> [<c0230c9a>] ppp_channel_push+0x41/0x9a
> [<c0231a13>] ppp_write+0xc6/0xf2
> [<c015ec26>] vfs_write+0x7f/0xba
> [<c015f158>] sys_write+0x3d/0x64
> [<c01027de>] sysenter_past_esp+0x5f/0x99
> [<ffffffff>] 0xffffffff
>
> other info that might help us debug this:
>
> 1 lock held by pppd/8926:
> #0: (&pch->downl){-+..}, at: [<c0230c72>] ppp_channel_push+0x19/0x9a
>
> stack backtrace:
> [<c0103834>] show_trace_log_lvl+0x1a/0x30
> [<c0103f16>] show_trace+0x12/0x14
> [<c0103f9d>] dump_stack+0x16/0x18
> [<c01343cd>] print_circular_bug_tail+0x68/0x71
> [<c0136289>] __lock_acquire+0xcc0/0x1010
> [<c0136642>] lock_acquire+0x69/0x83
> [<c02afbd6>] _spin_lock+0x2b/0x38
> [<c0265486>] dev_queue_xmit+0x247/0x2f1
> [<c02334f6>] __pppoe_xmit+0x1a9/0x215
> [<c023356c>] pppoe_xmit+0xa/0xc
> [<c0230c9a>] ppp_channel_push+0x41/0x9a
> [<c0231a13>] ppp_write+0xc6/0xf2
> [<c015ec26>] vfs_write+0x7f/0xba
> [<c015f158>] sys_write+0x3d/0x64
> [<c01027de>] sysenter_past_esp+0x5f/0x99
> =======================
> Clocksource tsc unstable (delta = 4686844667 ns)
> Time: acpi_pm clocksource has been installed.
...
lockdep has seen locks "-> #0" - "-> #3" taken in circular
order, but IMHO, lock "-> #3" (&pch->downl) taken after
"-> #2" (&ppp->wlock) differs from &pch->downl lock taken in
"-> #0" (before &vlan_netdev_xmit_lock_key) and lockdep
should be notified about this.
This patch proposal needs confirmation by some PPP expert
that channels processed in ppp_channel_push() differ from
channels processed in ppp_xmit_process(), so the same channel
cannot be processed by turns with both these functions.
I also hope Yuriy could test this patch (this should apply to
2.6.21-rc4 or later, CONFIG_PROVE_LOCKING = y), thanks.
Reported & tested by: "Yuriy N. Shkandybin" <jura@netams.com>
Signed-off-by: Jarek Poplawski <jarkao2@o2.pl>
(don't apply without above mentioned acks)
---
diff -Nurp 2.6.21-rc5-git1-/drivers/net/ppp_generic.c 2.6.21-rc5-git1/drivers/net/ppp_generic.c
--- 2.6.21-rc5-git1-/drivers/net/ppp_generic.c 2007-03-27 20:24:30.000000000 +0200
+++ 2.6.21-rc5-git1/drivers/net/ppp_generic.c 2007-03-27 20:34:44.000000000 +0200
@@ -1435,7 +1435,8 @@ ppp_channel_push(struct channel *pch)
struct sk_buff *skb;
struct ppp *ppp;
- spin_lock_bh(&pch->downl);
+ local_bh_disable();
+ spin_lock_nested(&pch->downl, SINGLE_DEPTH_NESTING);
if (pch->chan != 0) {
while (!skb_queue_empty(&pch->file.xq)) {
skb = skb_dequeue(&pch->file.xq);
@@ -1449,7 +1450,8 @@ ppp_channel_push(struct channel *pch)
/* channel got deregistered */
skb_queue_purge(&pch->file.xq);
}
- spin_unlock_bh(&pch->downl);
+ spin_unlock(&pch->downl);
+ local_bh_enable();
/* see if there is anything from the attached unit to be sent */
if (skb_queue_empty(&pch->file.xq)) {
read_lock_bh(&pch->upl);
next prev parent reply other threads:[~2007-03-28 8:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200703052226.l25MQUk4011469@fire-2.osdl.org>
2007-03-05 23:13 ` [Bugme-new] [Bug 8132] New: pptp server lockup in ppp_asynctty_receive() Andrew Morton
2007-03-08 8:45 ` Jarek Poplawski
2007-03-09 8:40 ` Yuriy N. Shkandybin
2007-03-09 10:21 ` Jarek Poplawski
2007-03-09 13:10 ` Jarek Poplawski
2007-03-09 13:10 ` Jarek Poplawski
2007-03-19 7:49 ` Yuriy N. Shkandybin
2007-03-19 7:49 ` Yuriy N. Shkandybin
2007-03-28 8:19 ` Jarek Poplawski [this message]
2007-03-28 8:19 ` [PATCH] ppp_generic: lockdep warning Re: [Bug 8132] New: pptp server lockup Jarek Poplawski
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=20070328081955.GA2363@ff.dom.local \
--to=jarkao2@o2.pl \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=jura@netams.com \
--cc=linux-ppp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulus@samba.org \
/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.