mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Anton Altaparmakov <aia21@cam.ac.uk>
To: Miles Lane <miles.lane@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: 2.6.17-rc6-mm1 -- BUG: possible circular locking deadlock detected!
Date: Thu, 08 Jun 2006 08:32:33 +0100	[thread overview]
Message-ID: <1149751953.10056.10.camel@imp.csi.cam.ac.uk> (raw)
In-Reply-To: <a44ae5cd0606072127n761c64fepf388e2f9de8ca1fe@mail.gmail.com>

Hi,

Thanks for the report.

On Wed, 2006-06-07 at 21:27 -0700, Miles Lane wrote:
> =====================================================
> [ BUG: possible circular locking deadlock detected! ]
> -----------------------------------------------------
> mount/1219 is trying to acquire lock:
>  (&ni->mrec_lock){--..}, at: [<c031e4b8>] mutex_lock+0x21/0x24
> 
> but task is already holding lock:
>  (&rl->lock){----}, at: [<f8a98e4d>] ntfs_map_runlist+0x2a/0xb5 [ntfs]
> 
> which lock already depends on the new lock,
> which could lead to circular deadlocks!

That's rubbish.  The lock analyser is not intelligent enough for
ntfs...  )-:

FWIW it appears to be picking up that locks depend on each other even
when they relate to different inodes which means that they do not depend
on each other.  It perhaps is getting confused by the special case for
the table of inodes ($MFT) which has the lock dependency reverse to all
other inodes but it is special because it can never take the lock
recursively (and hence deadlock) because we always keep the whole
runlist for $MFT in memory and should a bug or memory corruption cause
this not to be the case then ntfs will detect this and go BUG() so it
still will not deadlock...

The people responsible for the lock analyser will need to fix this in
their code or by adding some magic to ntfs to make the errors go away...

Best regards,

	Anton

> the existing dependency chain (in reverse order) is:
> 
> -> #1 (&rl->lock){----}:
>        [<c012ec64>] lock_acquire+0x58/0x74
>        [<f8a97619>] ntfs_readpage+0x362/0x8fd [ntfs]
>        [<c01415b0>] read_cache_page+0x8c/0x137
>        [<f8a9eeb8>] map_mft_record+0xd7/0x1d2 [ntfs]
>        [<f8a9d661>] ntfs_read_locked_inode+0x74/0xea9 [ntfs]
>        [<f8a9eabb>] ntfs_read_inode_mount+0x625/0x846 [ntfs]
>        [<f8aa2ff8>] ntfs_fill_super+0x8ca/0xd14 [ntfs]
>        [<c01647c4>] get_sb_bdev+0xed/0x14e
>        [<f8aa15ef>] ntfs_get_sb+0x10/0x12 [ntfs]
>        [<c0163c11>] vfs_kern_mount+0x76/0x143
>        [<c0163d17>] do_kern_mount+0x29/0x3d
>        [<c0177f9f>] do_mount+0x78a/0x7e4
>        [<c0178058>] sys_mount+0x5f/0x91
>        [<c031fb5d>] sysenter_past_esp+0x56/0x8d
> 
> -> #0 (&ni->mrec_lock){--..}:
>        [<c012ec64>] lock_acquire+0x58/0x74
>        [<c031e321>] __mutex_lock_slowpath+0xa7/0x21d
>        [<c031e4b8>] mutex_lock+0x21/0x24
>        [<f8a9edfa>] map_mft_record+0x19/0x1d2 [ntfs]
>        [<f8a98630>] ntfs_map_runlist_nolock+0x48/0x437 [ntfs]
>        [<f8a98eaa>] ntfs_map_runlist+0x87/0xb5 [ntfs]
>        [<f8a97739>] ntfs_readpage+0x482/0x8fd [ntfs]
>        [<c01415b0>] read_cache_page+0x8c/0x137
>        [<f8aa20bc>] load_system_files+0x155/0x7c7 [ntfs]
>        [<f8aa30a7>] ntfs_fill_super+0x979/0xd14 [ntfs]
>        [<c01647c4>] get_sb_bdev+0xed/0x14e
>        [<f8aa15ef>] ntfs_get_sb+0x10/0x12 [ntfs]
>        [<c0163c11>] vfs_kern_mount+0x76/0x143
>        [<c0163d17>] do_kern_mount+0x29/0x3d
>        [<c0177f9f>] do_mount+0x78a/0x7e4
>        [<c0178058>] sys_mount+0x5f/0x91
>        [<c031fb5d>] sysenter_past_esp+0x56/0x8d
> 
> other info that might help us debug this:
> 
> 2 locks held by mount/1219:
>  #0:  (&s->s_umount#18){--..}, at: [<c0164443>] sget+0x223/0x3a1
>  #1:  (&rl->lock){----}, at: [<f8a98e4d>] ntfs_map_runlist+0x2a/0xb5 [ntfs]
> 
> stack backtrace:
>  [<c0103924>] show_trace_log_lvl+0x54/0xfd
>  [<c01049a9>] show_trace+0xd/0x10
>  [<c01049c3>] dump_stack+0x17/0x1c
>  [<c012cefb>] print_circular_bug_tail+0x59/0x64
>  [<c012e766>] __lock_acquire+0x7c2/0x97a
>  [<c012ec64>] lock_acquire+0x58/0x74
>  [<c031e321>] __mutex_lock_slowpath+0xa7/0x21d
>  [<c031e4b8>] mutex_lock+0x21/0x24
>  [<f8a9edfa>] map_mft_record+0x19/0x1d2 [ntfs]
>  [<f8a98630>] ntfs_map_runlist_nolock+0x48/0x437 [ntfs]
>  [<f8a98eaa>] ntfs_map_runlist+0x87/0xb5 [ntfs]
>  [<f8a97739>] ntfs_readpage+0x482/0x8fd [ntfs]
>  [<c01415b0>] read_cache_page+0x8c/0x137
>  [<f8aa20bc>] load_system_files+0x155/0x7c7 [ntfs]
>  [<f8aa30a7>] ntfs_fill_super+0x979/0xd14 [ntfs]
>  [<c01647c4>] get_sb_bdev+0xed/0x14e
>  [<f8aa15ef>] ntfs_get_sb+0x10/0x12 [ntfs]
>  [<c0163c11>] vfs_kern_mount+0x76/0x143
>  [<c0163d17>] do_kern_mount+0x29/0x3d
>  [<c0177f9f>] do_mount+0x78a/0x7e4
>  [<c0178058>] sys_mount+0x5f/0x91
>  [<c031fb5d>] sysenter_past_esp+0x56/0x8d
> NTFS volume version 3.1.

-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/


  reply	other threads:[~2006-06-08  7:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-08  4:27 Miles Lane
2006-06-08  7:32 ` Anton Altaparmakov [this message]
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
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=1149751953.10056.10.camel@imp.csi.cam.ac.uk \
    --to=aia21@cam.ac.uk \
    --cc=akpm@osdl.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

all inboxes | Powered by JetHome®