All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.