From: Dave Jones <davej@redhat.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: recursive locking (coredump/vfs_write)
Date: Wed, 13 Nov 2013 16:11:47 -0500 [thread overview]
Message-ID: <20131113211147.GA30263@redhat.com> (raw)
Hey Al,
here's another one..
=============================================
[ INFO: possible recursive locking detected ]
3.12.0+ #2 Not tainted
---------------------------------------------
trinity-child3/13302 is trying to acquire lock:
(sb_writers#5){.+.+.+}, at: [<ffffffff811b7013>] vfs_write+0x173/0x1f0
but task is already holding lock:
(sb_writers#5){.+.+.+}, at: [<ffffffff8122006d>] do_coredump+0xf1d/0x1070
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sb_writers#5);
lock(sb_writers#5);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by trinity-child3/13302:
#0: (sb_writers#5){.+.+.+}, at: [<ffffffff8122006d>] do_coredump+0xf1d/0x1070
stack backtrace:
CPU: 3 PID: 13302 Comm: trinity-child3 Not tainted 3.12.0+ #2
ffffffff82526e10 ffff8801b54af820 ffffffff8171b3dc ffffffff82526e10
ffff8801b54af8e0 ffffffff810d722b 00007f93d6ce5000 0000000000000000
ffff880154b3f200 ffff880100000000 00000000004da26d ffffffff821b3901
Call Trace:
[<ffffffff8171b3dc>] dump_stack+0x4e/0x7a
[<ffffffff810d722b>] __lock_acquire+0x19ab/0x19f0
[<ffffffff81729334>] ? __do_page_fault+0x264/0x610
[<ffffffff8100b144>] ? native_sched_clock+0x24/0x80
[<ffffffff810d1d1f>] ? trace_hardirqs_off_caller+0x1f/0xc0
[<ffffffff810d7a23>] lock_acquire+0x93/0x1c0
[<ffffffff811b7013>] ? vfs_write+0x173/0x1f0
[<ffffffff811b97f9>] __sb_start_write+0xc9/0x1a0
[<ffffffff811b7013>] ? vfs_write+0x173/0x1f0
[<ffffffff811b7013>] ? vfs_write+0x173/0x1f0
[<ffffffff812cc303>] ? security_file_permission+0x23/0xa0
[<ffffffff811b7013>] vfs_write+0x173/0x1f0
[<ffffffff8121ef02>] dump_emit+0x92/0xd0
[<ffffffff81218d50>] elf_core_dump+0xde0/0x1740
[<ffffffff81218832>] ? elf_core_dump+0x8c2/0x1740
[<ffffffff8121fdee>] do_coredump+0xc9e/0x1070
[<ffffffff81719d9b>] ? __slab_free+0x191/0x35d
[<ffffffff8106a9b8>] get_signal_to_deliver+0x2c8/0x930
[<ffffffff810024b8>] do_signal+0x48/0x610
[<ffffffff810d1e39>] ? get_lock_stats+0x19/0x60
[<ffffffff810d25ae>] ? put_lock_stats.isra.28+0xe/0x30
[<ffffffff81715e86>] ? pagefault_enable+0xe/0x21
[<ffffffff8114b86e>] ? context_tracking_user_exit+0x4e/0x190
[<ffffffff810d54c5>] ? trace_hardirqs_on_caller+0x115/0x1e0
[<ffffffff81002adc>] do_notify_resume+0x5c/0xa0
[<ffffffff81725f86>] retint_signal+0x46/0x90
next reply other threads:[~2013-11-13 21:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 21:11 Dave Jones [this message]
2013-11-15 10:18 ` recursive locking (coredump/vfs_write) Peter Wu
2013-11-22 21:11 ` Jan Kara
2013-11-22 23:52 ` Al Viro
2013-11-24 9:31 ` Jan Kara
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=20131113211147.GA30263@redhat.com \
--to=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.