From: Arjan van de Ven <arjan@infradead.org>
To: Duncan Sands <duncan.sands@math.u-psud.fr>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@elte.hu>,
chas@cmf.nrl.navy.mil
Subject: Re: possible recursive locking in ATM layer
Date: Tue, 04 Jul 2006 18:13:02 +0200 [thread overview]
Message-ID: <1152029582.3109.70.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <200607041759.43064.duncan.sands@math.u-psud.fr>
From: Arjan van de Ven <arjan@linux.intel.com>
> Linux version 2.6.17-git22 (duncan@baldrick) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #20 PREEMPT Tue Jul 4 10:35:04 CEST 2006
>
> [ 2381.598609] =============================================
> [ 2381.619314] [ INFO: possible recursive locking detected ]
> [ 2381.635497] ---------------------------------------------
> [ 2381.651706] atmarpd/2696 is trying to acquire lock:
> [ 2381.666354] (&skb_queue_lock_key){-+..}, at: [<c028c540>] skb_migrate+0x24/0x6c
> [ 2381.688848]
ok this is a real potential deadlock in a way, it takes two locks of 2
skbuffs without doing any kind of lock ordering; I think the following
patch should fix it. Just sort the lock taking order by address of the
skb.. it's not pretty but it's the best this can do in a minimally
invasive way.
I still agree with the comment that this code shouldn't live in the atm
layer...
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
net/atm/ipcommon.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
Index: linux-2.6.17-mm6/net/atm/ipcommon.c
===================================================================
--- linux-2.6.17-mm6.orig/net/atm/ipcommon.c
+++ linux-2.6.17-mm6/net/atm/ipcommon.c
@@ -25,8 +25,8 @@
/*
* skb_migrate appends the list at "from" to "to", emptying "from" in the
* process. skb_migrate is atomic with respect to all other skb operations on
- * "from" and "to". Note that it locks both lists at the same time, so beware
- * of potential deadlocks.
+ * "from" and "to". Note that it locks both lists at the same time, so to deal
+ * with the lock ordering, the locks are taken in address order.
*
* This function should live in skbuff.c or skbuff.h.
*/
@@ -39,8 +39,13 @@ void skb_migrate(struct sk_buff_head *fr
struct sk_buff *skb_to = (struct sk_buff *) to;
struct sk_buff *prev;
- spin_lock_irqsave(&from->lock,flags);
- spin_lock(&to->lock);
+ if (from<to) {
+ spin_lock_irqsave(&from->lock,flags);
+ spin_lock_nested(&to->lock, SINGLE_DEPTH_NESTING);
+ } else {
+ spin_lock_irqsave(&to->lock, flags);
+ spin_lock_nested(&from->lock, SINGLE_DEPTH_NESTING);
+ }
prev = from->prev;
from->next->prev = to->prev;
prev->next = skb_to;
next prev parent reply other threads:[~2006-07-04 16:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-04 15:59 Duncan Sands
2006-07-04 16:13 ` Arjan van de Ven [this message]
2006-07-05 10:23 ` Duncan Sands
2006-07-05 13:33 ` Avi Kivity
2006-07-05 13:42 ` Arjan van de Ven
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=1152029582.3109.70.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=chas@cmf.nrl.navy.mil \
--cc=duncan.sands@math.u-psud.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®