* btrfs/mmap lockdep report from 3.2
@ 2012-01-10 1:03 Dave Jones
2012-01-10 1:44 ` Chris Mason
0 siblings, 1 reply; 4+ messages in thread
From: Dave Jones @ 2012-01-10 1:03 UTC (permalink / raw)
To: Linux Kernel; +Cc: chris.mason
Just hit this with Linus' tree as of 37cfc3f67db9f2d907f6bfcfae590cdbbef623e8
Dave
[ 130.932837] ======================================================
[ 130.933032] [ INFO: possible circular locking dependency detected ]
[ 130.933032] 3.2.0+ #19 Not tainted
[ 130.933032] -------------------------------------------------------
[ 130.933032] firefox/1630 is trying to acquire lock:
[ 130.933032] (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffffa011fd5b>] btrfs_page_mkwrite+0x5b/0x310 [btrfs]
[ 130.933032]
[ 130.933032] but task is already holding lock:
[ 130.933032] (&mm->mmap_sem){++++++}, at: [<ffffffff816a38c8>] do_page_fault+0xe8/0x5d0
[ 130.933032]
[ 130.933032] which lock already depends on the new lock.
[ 130.933032]
[ 130.933032]
[ 130.933032] the existing dependency chain (in reverse order) is:
[ 130.933032]
[ 130.933032] -> #1 (&mm->mmap_sem){++++++}:
[ 130.933032] [<ffffffff810c60bd>] lock_acquire+0x9d/0x220
[ 130.933032] [<ffffffff81173cd0>] might_fault+0x80/0xb0
[ 130.933032] [<ffffffff811ce057>] filldir+0x77/0xe0
[ 130.933032] [<ffffffffa01163ff>] btrfs_real_readdir+0xbf/0x740 [btrfs]
[ 130.933032] [<ffffffff811ce328>] vfs_readdir+0xb8/0xf0
[ 130.933032] [<ffffffff811ce459>] sys_getdents+0x89/0x100
[ 130.933032] [<ffffffff816a7f69>] system_call_fastpath+0x16/0x1b
[ 130.933032]
[ 130.933032] -> #0 (&sb->s_type->i_mutex_key#13){+.+.+.}:
[ 130.933032] [<ffffffff810c5988>] __lock_acquire+0x1bf8/0x1c20
[ 130.933032] [<ffffffff810c60bd>] lock_acquire+0x9d/0x220
[ 130.933032] [<ffffffff8169cb5e>] __mutex_lock_common+0x5e/0x500
[ 130.933032] [<ffffffff8169d134>] mutex_lock_nested+0x44/0x50
[ 130.933032] [<ffffffffa011fd5b>] btrfs_page_mkwrite+0x5b/0x310 [btrfs]
[ 130.933032] [<ffffffff81175806>] do_wp_page+0x586/0x720
[ 130.933032] [<ffffffff8117705d>] handle_pte_fault+0x27d/0xa10
[ 130.933032] [<ffffffff81177b98>] handle_mm_fault+0x1e8/0x2f0
[ 130.933032] [<ffffffff816a3949>] do_page_fault+0x169/0x5d0
[ 130.933032] [<ffffffff816a0ae5>] page_fault+0x25/0x30
[ 130.933032]
[ 130.933032] other info that might help us debug this:
[ 130.933032]
[ 130.933032] Possible unsafe locking scenario:
[ 130.933032]
[ 130.933032] CPU0 CPU1
[ 130.933032] ---- ----
[ 130.933032] lock(&mm->mmap_sem);
[ 130.933032] lock(&sb->s_type->i_mutex_key#13);
[ 130.933032] lock(&mm->mmap_sem);
[ 130.933032] lock(&sb->s_type->i_mutex_key#13);
[ 130.933032]
[ 130.933032] *** DEADLOCK ***
[ 130.933032]
[ 130.933032] 1 lock held by firefox/1630:
[ 130.933032] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff816a38c8>] do_page_fault+0xe8/0x5d0
[ 130.933032]
[ 130.933032] stack backtrace:
[ 130.933032] Pid: 1630, comm: firefox Not tainted 3.2.0+ #19
[ 130.933032] Call Trace:
[ 130.933032] [<ffffffff816932f2>] print_circular_bug+0x1fb/0x20c
[ 130.933032] [<ffffffff810c5988>] __lock_acquire+0x1bf8/0x1c20
[ 130.933032] [<ffffffff810c60bd>] lock_acquire+0x9d/0x220
[ 130.933032] [<ffffffffa011fd5b>] ? btrfs_page_mkwrite+0x5b/0x310 [btrfs]
[ 130.933032] [<ffffffff810221b9>] ? sched_clock+0x9/0x10
[ 130.933032] [<ffffffff810a4905>] ? sched_clock_local+0x25/0x90
[ 130.933032] [<ffffffff8169cb5e>] __mutex_lock_common+0x5e/0x500
[ 130.933032] [<ffffffffa011fd5b>] ? btrfs_page_mkwrite+0x5b/0x310 [btrfs]
[ 130.933032] [<ffffffff810221b9>] ? sched_clock+0x9/0x10
[ 130.933032] [<ffffffffa011fd5b>] ? btrfs_page_mkwrite+0x5b/0x310 [btrfs]
[ 130.933032] [<ffffffff8169d134>] mutex_lock_nested+0x44/0x50
[ 130.933032] [<ffffffffa011fd5b>] btrfs_page_mkwrite+0x5b/0x310 [btrfs]
[ 130.933032] [<ffffffff81175806>] do_wp_page+0x586/0x720
[ 130.933032] [<ffffffff8117705d>] handle_pte_fault+0x27d/0xa10
[ 130.933032] [<ffffffff810c066e>] ? put_lock_stats+0xe/0x40
[ 130.933032] [<ffffffff810c0fd7>] ? lock_release_holdtime.part.10+0xd7/0x150
[ 130.933032] [<ffffffff816a40bd>] ? sub_preempt_count+0x9d/0xd0
[ 130.933032] [<ffffffff81177b98>] handle_mm_fault+0x1e8/0x2f0
[ 130.933032] [<ffffffff816a3949>] do_page_fault+0x169/0x5d0
[ 130.933032] [<ffffffff813271ad>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 130.933032] [<ffffffff816a0ae5>] page_fault+0x25/0x30
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: btrfs/mmap lockdep report from 3.2
2012-01-10 1:03 btrfs/mmap lockdep report from 3.2 Dave Jones
@ 2012-01-10 1:44 ` Chris Mason
2012-01-17 23:25 ` Jan Kara
0 siblings, 1 reply; 4+ messages in thread
From: Chris Mason @ 2012-01-10 1:44 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel
On Mon, Jan 09, 2012 at 08:03:32PM -0500, Dave Jones wrote:
> Just hit this with Linus' tree as of 37cfc3f67db9f2d907f6bfcfae590cdbbef623e8
>
> Dave
>
> [ 130.932837] ======================================================
> [ 130.933032] [ INFO: possible circular locking dependency detected ]
> [ 130.933032] 3.2.0+ #19 Not tainted
> [ 130.933032] -------------------------------------------------------
> [ 130.933032] firefox/1630 is trying to acquire lock:
> [ 130.933032] (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffffa011fd5b>] btrfs_page_mkwrite+0x5b/0x310 [btrfs]
> [ 130.933032]
> [ 130.933032] but task is already holding lock:
> [ 130.933032] (&mm->mmap_sem){++++++}, at: [<ffffffff816a38c8>] do_page_fault+0xe8/0x5d0
> [ 130.933032]
> [ 130.933032] which lock already depends on the new lock.
>From a lockdep point of view, this is real. But the page_mkwrite
code is never called on directories so it is actually safe. We'll fix
it up.
-chris
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: btrfs/mmap lockdep report from 3.2
2012-01-10 1:44 ` Chris Mason
@ 2012-01-17 23:25 ` Jan Kara
2012-01-18 1:06 ` Chris Mason
0 siblings, 1 reply; 4+ messages in thread
From: Jan Kara @ 2012-01-17 23:25 UTC (permalink / raw)
To: Chris Mason; +Cc: Dave Jones, Linux Kernel
On Mon 09-01-12 20:44:32, Chris Mason wrote:
> On Mon, Jan 09, 2012 at 08:03:32PM -0500, Dave Jones wrote:
> > Just hit this with Linus' tree as of 37cfc3f67db9f2d907f6bfcfae590cdbbef623e8
> >
> > Dave
> >
> > [ 130.932837] ======================================================
> > [ 130.933032] [ INFO: possible circular locking dependency detected ]
> > [ 130.933032] 3.2.0+ #19 Not tainted
> > [ 130.933032] -------------------------------------------------------
> > [ 130.933032] firefox/1630 is trying to acquire lock:
> > [ 130.933032] (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffffa011fd5b>] btrfs_page_mkwrite+0x5b/0x310 [btrfs]
> > [ 130.933032]
> > [ 130.933032] but task is already holding lock:
> > [ 130.933032] (&mm->mmap_sem){++++++}, at: [<ffffffff816a38c8>] do_page_fault+0xe8/0x5d0
> > [ 130.933032]
> > [ 130.933032] which lock already depends on the new lock.
>
> From a lockdep point of view, this is real. But the page_mkwrite
> code is never called on directories so it is actually safe. We'll fix
> it up.
Well, but hitting a fault (and thus acquiring mmap_sem) while holding
i_mutex can happen also for normal files when we copy data from userspace.
So I believe the deadlock is real...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: btrfs/mmap lockdep report from 3.2
2012-01-17 23:25 ` Jan Kara
@ 2012-01-18 1:06 ` Chris Mason
0 siblings, 0 replies; 4+ messages in thread
From: Chris Mason @ 2012-01-18 1:06 UTC (permalink / raw)
To: Jan Kara; +Cc: Dave Jones, Linux Kernel
On Wed, Jan 18, 2012 at 12:25:50AM +0100, Jan Kara wrote:
> On Mon 09-01-12 20:44:32, Chris Mason wrote:
> > On Mon, Jan 09, 2012 at 08:03:32PM -0500, Dave Jones wrote:
> > > Just hit this with Linus' tree as of 37cfc3f67db9f2d907f6bfcfae590cdbbef623e8
> > >
> > > Dave
> > >
> > > [ 130.932837] ======================================================
> > > [ 130.933032] [ INFO: possible circular locking dependency detected ]
> > > [ 130.933032] 3.2.0+ #19 Not tainted
> > > [ 130.933032] -------------------------------------------------------
> > > [ 130.933032] firefox/1630 is trying to acquire lock:
> > > [ 130.933032] (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffffa011fd5b>] btrfs_page_mkwrite+0x5b/0x310 [btrfs]
> > > [ 130.933032]
> > > [ 130.933032] but task is already holding lock:
> > > [ 130.933032] (&mm->mmap_sem){++++++}, at: [<ffffffff816a38c8>] do_page_fault+0xe8/0x5d0
> > > [ 130.933032]
> > > [ 130.933032] which lock already depends on the new lock.
> >
> > From a lockdep point of view, this is real. But the page_mkwrite
> > code is never called on directories so it is actually safe. We'll fix
> > it up.
> Well, but hitting a fault (and thus acquiring mmap_sem) while holding
> i_mutex can happen also for normal files when we copy data from userspace.
> So I believe the deadlock is real...
Al mentioned this as well. Josef patched it up (its in my pull request)
and I'll send a fix to -stable.
-chris
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-01-18 1:07 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-10 1:03 btrfs/mmap lockdep report from 3.2 Dave Jones
2012-01-10 1:44 ` Chris Mason
2012-01-17 23:25 ` Jan Kara
2012-01-18 1:06 ` Chris Mason
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).