From: Ingo Molnar <mingo@elte.hu>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: Miles Lane <miles.lane@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: 2.6.17-rc6-mm1 -- BUG: possible circular locking deadlock detected!
Date: Mon, 12 Jun 2006 10:31:17 +0200 [thread overview]
Message-ID: <20060612083117.GA29026@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.64.0606110739310.3726@hermes-1.csi.cam.ac.uk>
* Anton Altaparmakov <aia21@cam.ac.uk> wrote:
> First an explanation of two relevant locks that are both going to
> upset the validator. I half expected this to happen given what has
> happened so far. The two locks are lcnbmp_lock and mftbmp_lock (both
> are r/w semaphores).
thanks!
> Is the above description sufficient for you to fix it?
yeah. I have split off vol->lcnbmp_ino's locking rules (for mrec_lock
and runlist.lock) from normal inode locking rules, and this fixed the
file-writing dependency.
but i can still trigger a warning, and i think this time it's a real
bug: if i mount NTFS with -o show_system_files, and i append data to the
$Bitmap, then i get the dependency conflict attached further below.
While extending the $Bitmap manually is extremely evil, the filesystem
should nevertheless not break - for example a script could do it by
accident. I believe NTFS should either disallow writing to the $Bitmap
(by forcing it to be readonly under all circumstances), or the writing
should be made safe - right now if that happens in parallel to some
other process extending an NTFS file then i think we could deadlock,
right?
Ingo
=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
cat/2532 is trying to acquire lock:
(&vol->lcnbmp_lock){----}, at: [<c01e809d>] ntfs_cluster_alloc+0x10d/0x23a0
but task is already holding lock:
(lcnbmp_mrec_lock){--..}, at: [<c01d5dc3>] map_mft_record+0x53/0x2c0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (lcnbmp_mrec_lock){--..}:
[<c013948f>] lock_acquire+0x6f/0x90
[<c0346163>] mutex_lock_nested+0x73/0x2a0
[<c01d5dc3>] map_mft_record+0x53/0x2c0
[<c01c5498>] ntfs_map_runlist_nolock+0x3d8/0x530
[<c01c5b61>] ntfs_map_runlist+0x41/0x70
[<c01c18d1>] ntfs_readpage+0x8c1/0x9a0
[<c0142fac>] read_cache_page+0xac/0x150
[<c01e20ad>] ntfs_statfs+0x41d/0x660
[<c0163204>] vfs_statfs+0x54/0x70
[<c0163238>] vfs_statfs64+0x18/0x30
[<c0163334>] sys_statfs64+0x64/0xa0
[<c0347dad>] sysenter_past_esp+0x56/0x8d
-> #1 (lcnbmp_runlist_lock){----}:
[<c013948f>] lock_acquire+0x6f/0x90
[<c0134c4c>] down_read+0x2c/0x40
[<c01c184c>] ntfs_readpage+0x83c/0x9a0
[<c0142fac>] read_cache_page+0xac/0x150
[<c01e20ad>] ntfs_statfs+0x41d/0x660
[<c0163204>] vfs_statfs+0x54/0x70
[<c0163238>] vfs_statfs64+0x18/0x30
[<c0163334>] sys_statfs64+0x64/0xa0
[<c0347dad>] sysenter_past_esp+0x56/0x8d
-> #0 (&vol->lcnbmp_lock){----}:
[<c013948f>] lock_acquire+0x6f/0x90
[<c0134ccc>] down_write+0x2c/0x50
[<c01e809d>] ntfs_cluster_alloc+0x10d/0x23a0
[<c01c421d>] ntfs_attr_extend_allocation+0x5fd/0x14a0
[<c01ca9d8>] ntfs_file_buffered_write+0x188/0x3880
[<c01ce248>] ntfs_file_aio_write_nolock+0x178/0x210
[<c01ce391>] ntfs_file_writev+0xb1/0x150
[<c01ce44f>] ntfs_file_write+0x1f/0x30
[<c0164eb9>] vfs_write+0x99/0x160
[<c016584d>] sys_write+0x3d/0x70
[<c0347dad>] sysenter_past_esp+0x56/0x8d
other info that might help us debug this:
3 locks held by cat/2532:
#0: (&inode->i_mutex){--..}, at: [<c03460e8>] mutex_lock+0x8/0x10
#1: (lcnbmp_runlist_lock){----}, at: [<c01c3d5e>] ntfs_attr_extend_allocation+0x13e/0x14a0
#2: (lcnbmp_mrec_lock){--..}, at: [<c01d5dc3>] map_mft_record+0x53/0x2c0
stack backtrace:
[<c0104bf2>] show_trace+0x12/0x20
[<c0104c19>] dump_stack+0x19/0x20
[<c0136f11>] print_circular_bug_tail+0x61/0x70
[<c01389af>] __lock_acquire+0x6df/0xd70
[<c013948f>] lock_acquire+0x6f/0x90
[<c0134ccc>] down_write+0x2c/0x50
[<c01e809d>] ntfs_cluster_alloc+0x10d/0x23a0
[<c01c421d>] ntfs_attr_extend_allocation+0x5fd/0x14a0
[<c01ca9d8>] ntfs_file_buffered_write+0x188/0x3880
[<c01ce248>] ntfs_file_aio_write_nolock+0x178/0x210
[<c01ce391>] ntfs_file_writev+0xb1/0x150
[<c01ce44f>] ntfs_file_write+0x1f/0x30
[<c0164eb9>] vfs_write+0x99/0x160
[<c016584d>] sys_write+0x3d/0x70
[<c0347dad>] sysenter_past_esp+0x56/0x8d
next prev parent reply other threads:[~2006-06-12 8:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-08 4:27 2.6.17-rc6-mm1 -- BUG: possible circular locking deadlock detected! Miles Lane
2006-06-08 7:32 ` Anton Altaparmakov
2006-06-08 9:55 ` Ingo Molnar
2006-06-08 10:53 ` Anton Altaparmakov
2006-06-08 11:23 ` Ingo Molnar
2006-06-09 8:09 ` Anton Altaparmakov
2006-06-10 7:59 ` Ingo Molnar
2006-06-10 8:48 ` Anton Altaparmakov
2006-06-11 5:31 ` Ingo Molnar
2006-06-11 7:10 ` Anton Altaparmakov
2006-06-12 8:31 ` Ingo Molnar [this message]
2006-06-12 8:47 ` Anton Altaparmakov
2006-06-12 9:40 ` Ingo Molnar
2006-06-12 10:24 ` Anton Altaparmakov
2006-06-12 10:56 ` Ingo Molnar
2006-06-13 5:41 ` Miles Lane
2006-06-13 21:18 ` Ingo Molnar
2006-06-08 16:11 ` Ingo Molnar
2006-06-08 21:17 ` Anton Altaparmakov
2006-06-09 7:19 ` Ingo Molnar
2006-06-09 8:31 ` Anton Altaparmakov
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=20060612083117.GA29026@elte.hu \
--to=mingo@elte.hu \
--cc=aia21@cam.ac.uk \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--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