From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Miles Lane <miles.lane@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.18 -- INFO: possible recursive locking detected
Date: Fri, 22 Sep 2006 14:29:59 +0200 [thread overview]
Message-ID: <4513D747.7000003@s5r6.in-berlin.de> (raw)
In-Reply-To: <a44ae5cd0609211447i41ae58f3xa59d2ae4c5dc5f65@mail.gmail.com>
Miles Lane wrote:
> =============================================
> [ INFO: possible recursive locking detected ]
> ---------------------------------------------
> knodemgrd_1/13913 is trying to acquire lock:
> (&s->rwsem){..--}, at: [<f8960817>] nodemgr_probe_ne+0x22d/0x36c [ieee1394]
>
> but task is already holding lock:
> (&s->rwsem){..--}, at: [<f89610d8>] nodemgr_host_thread+0x739/0x8a7 [ieee1394]
Thanks for the report.
There is already a fix in -mm and linux1394-2.6.git which will
presumably appear in 2.6.19-rc1.
http://kernel.org/git/?p=linux/kernel/git/ieee1394/linux1394-2.6.git;a=commitdiff_plain;h=9b516010863195ba7db061233a3eeffe779130e8
To verify the fix, you can probably apply this patch as-is to Linux
2.6.18. Alternatively you can get it with this patchset:
http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.18-rc6/
(You need v159 or later to get the recursive locking fix. I will ready a
patchset against 2.6.18 soon but I expect it to be the same as against
2.6.18-rc6.)
> other info that might help us debug this:
> 1 lock held by knodemgrd_1/13913:
> #0: (&s->rwsem){..--}, at: [<f89610d8>]
> nodemgr_host_thread+0x739/0x8a7 [ieee1394]
>
> stack backtrace:
> [<c1003ef5>] show_trace_log_lvl+0x58/0x16a
> [<c100506d>] show_trace+0xd/0x10
> [<c1005087>] dump_stack+0x17/0x1c
> [<c102e485>] __lock_acquire+0x79b/0x9ef
> [<c102e9b6>] lock_acquire+0x5e/0x80
> [<c102b73e>] down_read+0x28/0x3a
> [<f8960817>] nodemgr_probe_ne+0x22d/0x36c [ieee1394]
> [<f89610f7>] nodemgr_host_thread+0x758/0x8a7 [ieee1394]
> [<c1001005>] kernel_thread_helper+0x5/0xb
> DWARF2 unwinder stuck at kernel_thread_helper+0x5/0xb
> Leftover inexact backtrace:
> [<c100506d>] show_trace+0xd/0x10
> [<c1005087>] dump_stack+0x17/0x1c
> [<c102e485>] __lock_acquire+0x79b/0x9ef
> [<c102e9b6>] lock_acquire+0x5e/0x80
> [<c102b73e>] down_read+0x28/0x3a
> [<f8960817>] nodemgr_probe_ne+0x22d/0x36c [ieee1394]
> [<f89610f7>] nodemgr_host_thread+0x758/0x8a7 [ieee1394]
> [<c1001005>] kernel_thread_helper+0x5/0xb
> ieee1394: send packet at S400: ffc0a140 ffc1ffff f0000234
> -
--
Stefan Richter
-=====-=-==- =--= =--==
http://arcgraph.de/sr/
prev parent reply other threads:[~2006-09-22 12:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-21 21:47 Miles Lane
2006-09-22 12:29 ` Stefan Richter [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=4513D747.7000003@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=miles.lane@gmail.com \
/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®