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 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.