* possible circular locking dependency detected
@ 2007-05-13 18:11 Marko Macek
0 siblings, 0 replies; 7+ messages in thread
From: Marko Macek @ 2007-05-13 18:11 UTC (permalink / raw)
To: linux-kernel, video4linux-list
Hello!
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.21.1-cfs-v11 #4
-------------------------------------------------------
tvtime/6360 is trying to acquire lock:
(&mm->mmap_sem){----}, at: [<f8a6a50a>]
videobuf_dma_init_user+0xb6/0x14e [video_buf]
but task is already holding lock:
(&q->lock#2){--..}, at: [<f8a6ac43>] videobuf_qbuf+0x10/0x288 [video_buf]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&q->lock#2){--..}:
[<c01437eb>] __lock_acquire+0x9de/0xb58
[<f8a695fe>] videobuf_mmap_mapper+0x12/0x1ff [video_buf]
[<c0143d19>] lock_acquire+0x56/0x6e
[<f8a695fe>] videobuf_mmap_mapper+0x12/0x1ff [video_buf]
[<c032579a>] __mutex_lock_slowpath+0xe3/0x23b
[<f8a695fe>] videobuf_mmap_mapper+0x12/0x1ff [video_buf]
[<f8a695fe>] videobuf_mmap_mapper+0x12/0x1ff [video_buf]
[<c0173559>] kmem_cache_zalloc+0x69/0x97
[<c0142a07>] trace_hardirqs_on+0x11e/0x141
[<c0168eea>] do_mmap_pgoff+0x43e/0x714
[<c0108adb>] sys_mmap2+0x9d/0xb7
[<c0104d9e>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
-> #0 (&mm->mmap_sem){----}:
[<c014170f>] print_circular_bug_entry+0x40/0x46
[<c01436d7>] __lock_acquire+0x8ca/0xb58
[<f8a6a50a>] videobuf_dma_init_user+0xb6/0x14e [video_buf]
[<c0143d19>] lock_acquire+0x56/0x6e
[<f8a6a50a>] videobuf_dma_init_user+0xb6/0x14e [video_buf]
[<c013d082>] down_read+0x3d/0x4e
[<f8a6a50a>] videobuf_dma_init_user+0xb6/0x14e [video_buf]
[<f8a6a50a>] videobuf_dma_init_user+0xb6/0x14e [video_buf]
[<f8a69ae7>] videobuf_waiton+0xdf/0xe9 [video_buf]
[<f8a6a836>] videobuf_iolock+0x7f/0xdf [video_buf]
[<f8a7fdb2>] buffer_prepare+0x174/0x1d8 [saa7134]
[<c03258ea>] __mutex_lock_slowpath+0x233/0x23b
[<f8a6ac43>] videobuf_qbuf+0x10/0x288 [video_buf]
[<f8a6ae23>] videobuf_qbuf+0x1f0/0x288 [video_buf]
[<c0159626>] find_get_page+0x40/0x45
[<f8a8144d>] video_do_ioctl+0xd6f/0xec7 [saa7134]
[<c0326a8a>] _spin_unlock+0x14/0x1c
[<f8a0e946>] video_usercopy+0x172/0x237 [videodev]
[<c0328621>] do_page_fault+0x202/0x5df
[<f8a7ef74>] video_ioctl+0x18/0x1c [saa7134]
[<f8a806de>] video_do_ioctl+0x0/0xec7 [saa7134]
[<c0180ca0>] do_ioctl+0x4c/0x62
[<c0180efa>] vfs_ioctl+0x244/0x256
[<c0180f58>] sys_ioctl+0x4c/0x64
[<c0104d9e>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
other info that might help us debug this:
1 lock held by tvtime/6360:
#0: (&q->lock#2){--..}, at: [<f8a6ac43>] videobuf_qbuf+0x10/0x288
[video_buf]
stack backtrace:
[<c0141fa7>] print_circular_bug_tail+0x5f/0x67
[<c014170f>] print_circular_bug_entry+0x40/0x46
[<c01436d7>] __lock_acquire+0x8ca/0xb58
[<f8a6a50a>] videobuf_dma_init_user+0xb6/0x14e [video_buf]
[<c0143d19>] lock_acquire+0x56/0x6e
[<f8a6a50a>] videobuf_dma_init_user+0xb6/0x14e [video_buf]
[<c013d082>] down_read+0x3d/0x4e
[<f8a6a50a>] videobuf_dma_init_user+0xb6/0x14e [video_buf]
[<f8a6a50a>] videobuf_dma_init_user+0xb6/0x14e [video_buf]
[<f8a69ae7>] videobuf_waiton+0xdf/0xe9 [video_buf]
[<f8a6a836>] videobuf_iolock+0x7f/0xdf [video_buf]
[<f8a7fdb2>] buffer_prepare+0x174/0x1d8 [saa7134]
[<c03258ea>] __mutex_lock_slowpath+0x233/0x23b
[<f8a6ac43>] videobuf_qbuf+0x10/0x288 [video_buf]
[<f8a6ae23>] videobuf_qbuf+0x1f0/0x288 [video_buf]
[<c0159626>] find_get_page+0x40/0x45
[<f8a8144d>] video_do_ioctl+0xd6f/0xec7 [saa7134]
[<c0326a8a>] _spin_unlock+0x14/0x1c
[<f8a0e946>] video_usercopy+0x172/0x237 [videodev]
[<c0328621>] do_page_fault+0x202/0x5df
[<f8a7ef74>] video_ioctl+0x18/0x1c [saa7134]
[<f8a806de>] video_do_ioctl+0x0/0xec7 [saa7134]
[<c0180ca0>] do_ioctl+0x4c/0x62
[<c0180efa>] vfs_ioctl+0x244/0x256
[<c0180f58>] sys_ioctl+0x4c/0x64
[<c0104d9e>] sysenter_past_esp+0x5f/0x99
=======================
The TV card is saa7134.
Machine is AMD Athlon 64 X2. Fedora Core 6.
I get a lockup while watching TV about every month or two. Machine
responds to ping, but nothing else.
Mark
^ permalink raw reply [flat|nested] 7+ messages in thread
* possible circular locking dependency detected
@ 2010-05-20 16:34 Ciprian Docan
2010-05-21 21:14 ` Andrew Morton
0 siblings, 1 reply; 7+ messages in thread
From: Ciprian Docan @ 2010-05-20 16:34 UTC (permalink / raw)
To: linux-kernel
Hi,
I got the following in the dmesg:
--------------------------------------------------------------------
[ INFO: possible circular locking dependency detected ]
2.6.33-rc8 #4
-------------------------------------------------------
fdisk/29231 is trying to acquire lock:
(&type->s_umount_key#47){++++..}, at: [<ffffffff810fb13c>]
get_super+0x5c/0xaf
but task is already holding lock:
(&bdev->bd_mutex){+.+.+.}, at: [<ffffffff811f2df0>]
blkdev_ioctl+0x5c5/0x6b1
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&bdev->bd_mutex){+.+.+.}:
[<ffffffff8106e65b>] __lock_acquire+0xb5d/0xd05
[<ffffffff8106e8cf>] lock_acquire+0xcc/0xe9
[<ffffffff81402d09>] __mutex_lock_common+0x4c/0x348
[<ffffffff814030c9>] mutex_lock_nested+0x3e/0x43
[<ffffffff8111f4a9>] __blkdev_put+0x34/0x16c
[<ffffffff8111f5f1>] blkdev_put+0x10/0x12
[<ffffffff8112063b>] close_bdev_exclusive+0x24/0x2d
[<ffffffff810fbcaa>] get_sb_bdev+0xef/0x1a1
[<ffffffffa0114189>] vfat_get_sb+0x18/0x1a [vfat]
[<ffffffff810fb8bc>] vfs_kern_mount+0xa9/0x168
[<ffffffff810fb9e3>] do_kern_mount+0x4d/0xed
[<ffffffff81110f54>] do_mount+0x72f/0x7a6
[<ffffffff81111053>] sys_mount+0x88/0xc2
[<ffffffff8100236b>] system_call_fastpath+0x16/0x1b
-> #0 (&type->s_umount_key#47){++++..}:
[<ffffffff8106e505>] __lock_acquire+0xa07/0xd05
[<ffffffff8106e8cf>] lock_acquire+0xcc/0xe9
[<ffffffff81403450>] down_read+0x51/0x84
[<ffffffff810fb13c>] get_super+0x5c/0xaf
[<ffffffff8111facd>] fsync_bdev+0x18/0x48
[<ffffffff811f433c>] invalidate_partition+0x25/0x42
[<ffffffff8114bda2>] rescan_partitions+0x37/0x3a7
[<ffffffff811f2dff>] blkdev_ioctl+0x5d4/0x6b1
[<ffffffff8111eca4>] block_ioctl+0x37/0x3b
[<ffffffff811060d0>] vfs_ioctl+0x32/0xa6
[<ffffffff81106650>] do_vfs_ioctl+0x490/0x4d6
[<ffffffff811066ec>] sys_ioctl+0x56/0x79
[<ffffffff8100236b>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
1 lock held by fdisk/29231:
#0: (&bdev->bd_mutex){+.+.+.}, at: [<ffffffff811f2df0>]
blkdev_ioctl+0x5c5/0x6b1
stack backtrace:
Pid: 29231, comm: fdisk Not tainted 2.6.33-rc8 #4
Call Trace:
[<ffffffff8106d6dc>] print_circular_bug+0xa8/0xb6
[<ffffffff8106e505>] __lock_acquire+0xa07/0xd05
[<ffffffff81062009>] ? sched_clock_local+0x1c/0x82
[<ffffffff8106e8cf>] lock_acquire+0xcc/0xe9
[<ffffffff810fb13c>] ? get_super+0x5c/0xaf
[<ffffffff8106b936>] ? lock_release_holdtime+0x2c/0xdb
[<ffffffff81403450>] down_read+0x51/0x84
[<ffffffff810fb13c>] ? get_super+0x5c/0xaf
[<ffffffff810fb13c>] get_super+0x5c/0xaf
[<ffffffff8111facd>] fsync_bdev+0x18/0x48
[<ffffffff811f433c>] invalidate_partition+0x25/0x42
[<ffffffff81402c8e>] ? mutex_trylock+0x12a/0x159
[<ffffffff8114bda2>] rescan_partitions+0x37/0x3a7
[<ffffffff8106d0c9>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff811f2df0>] ? blkdev_ioctl+0x5c5/0x6b1
[<ffffffff811f2dff>] blkdev_ioctl+0x5d4/0x6b1
[<ffffffff8106d098>] ? trace_hardirqs_on_caller+0x118/0x13c
[<ffffffff8111eca4>] block_ioctl+0x37/0x3b
[<ffffffff811060d0>] vfs_ioctl+0x32/0xa6
[<ffffffff81106650>] do_vfs_ioctl+0x490/0x4d6
[<ffffffff811066ec>] sys_ioctl+0x56/0x79
[<ffffffff8102f9bd>] ? __wake_up+0x22/0x4d
[<ffffffff8100236b>] system_call_fastpath+0x16/0x1b
-------------------------------------------------------------------------
Kernel version used: 2.6.33-rc8 #4. I do not remember the exact steps, but
I was trying to format an USB stick using the fdisk. Please let me know if
you need additional informations. Thank you.
Regards,
--
Ciprian Docan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: possible circular locking dependency detected
2010-05-20 16:34 possible circular locking dependency detected Ciprian Docan
@ 2010-05-21 21:14 ` Andrew Morton
2010-05-22 14:52 ` [PATCH] vfs: don't hold s_umount over close_bdev_exclusive() call Tejun Heo
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2010-05-21 21:14 UTC (permalink / raw)
To: Ciprian Docan; +Cc: linux-kernel, Al Viro, Tejun Heo
On Thu, 20 May 2010 12:34:00 -0400 (EDT)
Ciprian Docan <docan@eden.rutgers.edu> wrote:
>
> Hi,
>
> I got the following in the dmesg:
>
> --------------------------------------------------------------------
> [ INFO: possible circular locking dependency detected ]
> 2.6.33-rc8 #4
> -------------------------------------------------------
> fdisk/29231 is trying to acquire lock:
> (&type->s_umount_key#47){++++..}, at: [<ffffffff810fb13c>]
> get_super+0x5c/0xaf
>
> but task is already holding lock:
> (&bdev->bd_mutex){+.+.+.}, at: [<ffffffff811f2df0>]
> blkdev_ioctl+0x5c5/0x6b1
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&bdev->bd_mutex){+.+.+.}:
> [<ffffffff8106e65b>] __lock_acquire+0xb5d/0xd05
> [<ffffffff8106e8cf>] lock_acquire+0xcc/0xe9
> [<ffffffff81402d09>] __mutex_lock_common+0x4c/0x348
> [<ffffffff814030c9>] mutex_lock_nested+0x3e/0x43
> [<ffffffff8111f4a9>] __blkdev_put+0x34/0x16c
> [<ffffffff8111f5f1>] blkdev_put+0x10/0x12
> [<ffffffff8112063b>] close_bdev_exclusive+0x24/0x2d
> [<ffffffff810fbcaa>] get_sb_bdev+0xef/0x1a1
> [<ffffffffa0114189>] vfat_get_sb+0x18/0x1a [vfat]
> [<ffffffff810fb8bc>] vfs_kern_mount+0xa9/0x168
> [<ffffffff810fb9e3>] do_kern_mount+0x4d/0xed
> [<ffffffff81110f54>] do_mount+0x72f/0x7a6
> [<ffffffff81111053>] sys_mount+0x88/0xc2
> [<ffffffff8100236b>] system_call_fastpath+0x16/0x1b
vfs_kern_mount() holds s_umount. My brain isn't large enough to work
out where that lock was taken, yet it's so obvious that no code
comments were needed. Sigh. Might be down under sget().
vfs_kern_mount() ends up calling into __blkdev_put(), which takes
bd_mutex.
> -> #0 (&type->s_umount_key#47){++++..}:
> [<ffffffff8106e505>] __lock_acquire+0xa07/0xd05
> [<ffffffff8106e8cf>] lock_acquire+0xcc/0xe9
> [<ffffffff81403450>] down_read+0x51/0x84
> [<ffffffff810fb13c>] get_super+0x5c/0xaf
> [<ffffffff8111facd>] fsync_bdev+0x18/0x48
> [<ffffffff811f433c>] invalidate_partition+0x25/0x42
> [<ffffffff8114bda2>] rescan_partitions+0x37/0x3a7
> [<ffffffff811f2dff>] blkdev_ioctl+0x5d4/0x6b1
> [<ffffffff8111eca4>] block_ioctl+0x37/0x3b
> [<ffffffff811060d0>] vfs_ioctl+0x32/0xa6
> [<ffffffff81106650>] do_vfs_ioctl+0x490/0x4d6
> [<ffffffff811066ec>] sys_ioctl+0x56/0x79
> [<ffffffff8100236b>] system_call_fastpath+0x16/0x1b
blkdev_reread_part() takes bd_mutex then does
rescan_partitions
->invalidate_partition
->fsync_bdev
->get_super (takes s_umount for reading)
> other info that might help us debug this:
>
> 1 lock held by fdisk/29231:
> #0: (&bdev->bd_mutex){+.+.+.}, at: [<ffffffff811f2df0>]
> blkdev_ioctl+0x5c5/0x6b1
>
> stack backtrace:
> Pid: 29231, comm: fdisk Not tainted 2.6.33-rc8 #4
> Call Trace:
> [<ffffffff8106d6dc>] print_circular_bug+0xa8/0xb6
> [<ffffffff8106e505>] __lock_acquire+0xa07/0xd05
> [<ffffffff81062009>] ? sched_clock_local+0x1c/0x82
> [<ffffffff8106e8cf>] lock_acquire+0xcc/0xe9
> [<ffffffff810fb13c>] ? get_super+0x5c/0xaf
> [<ffffffff8106b936>] ? lock_release_holdtime+0x2c/0xdb
> [<ffffffff81403450>] down_read+0x51/0x84
> [<ffffffff810fb13c>] ? get_super+0x5c/0xaf
> [<ffffffff810fb13c>] get_super+0x5c/0xaf
> [<ffffffff8111facd>] fsync_bdev+0x18/0x48
> [<ffffffff811f433c>] invalidate_partition+0x25/0x42
> [<ffffffff81402c8e>] ? mutex_trylock+0x12a/0x159
> [<ffffffff8114bda2>] rescan_partitions+0x37/0x3a7
> [<ffffffff8106d0c9>] ? trace_hardirqs_on+0xd/0xf
> [<ffffffff811f2df0>] ? blkdev_ioctl+0x5c5/0x6b1
> [<ffffffff811f2dff>] blkdev_ioctl+0x5d4/0x6b1
> [<ffffffff8106d098>] ? trace_hardirqs_on_caller+0x118/0x13c
> [<ffffffff8111eca4>] block_ioctl+0x37/0x3b
> [<ffffffff811060d0>] vfs_ioctl+0x32/0xa6
> [<ffffffff81106650>] do_vfs_ioctl+0x490/0x4d6
> [<ffffffff811066ec>] sys_ioctl+0x56/0x79
> [<ffffffff8102f9bd>] ? __wake_up+0x22/0x4d
> [<ffffffff8100236b>] system_call_fastpath+0x16/0x1b
> -------------------------------------------------------------------------
>
> Kernel version used: 2.6.33-rc8 #4. I do not remember the exact steps, but
> I was trying to format an USB stick using the fdisk. Please let me know if
> you need additional informations. Thank you.
>
So yup, that's ab/ba deadlockable. I cannot immediately see any change
which might have caused that. Tejun has been mucking with the
partitions code recently but nothing leaps out at me.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] vfs: don't hold s_umount over close_bdev_exclusive() call
2010-05-21 21:14 ` Andrew Morton
@ 2010-05-22 14:52 ` Tejun Heo
2010-05-25 8:30 ` Jens Axboe
0 siblings, 1 reply; 7+ messages in thread
From: Tejun Heo @ 2010-05-22 14:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ciprian Docan, linux-kernel, Al Viro, Jens Axboe
This patch fixes an obscure AB-BA deadlock in get_sb_bdev().
When a superblock is mounted more than once get_sb_bdev() calls
close_bdev_exclusive() to drop the extra bdev reference while holding
s_umount. However, sb->s_umount nests inside bd_mutex during
__invalidate_device() and close_bdev_exclusive() acquires bd_mutex
during blkdev_put(); thus creating an AB-BA deadlock.
This condition doesn't trigger frequently. For this condition to be
visible to lockdep, the filesystem must occupy the whole device (as
__invalidate_device() only grabs bd_mutex for the whole device), the
FS must be mounted more than once and partition rescan should be
issued while the FS is still mounted.
Fix it by dropping s_umount over close_bdev_exclusive().
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Ciprian Docan <docan@eden.rutgers.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
---
I think this fix is safe and seems to work fine here but I dunno know
the locking too well, so it would be best not to push it w/o Al's ack.
Thanks.
fs/super.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/fs/super.c b/fs/super.c
index 1527e6a..667f706 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -821,7 +821,16 @@ int get_sb_bdev(struct file_system_type *fs_type,
goto error_bdev;
}
+ /*
+ * s_umount nests inside bd_mutex during
+ * __invalidate_device(). close_bdev_exclusive()
+ * acquires bd_mutex and can't be called under
+ * s_umount. Drop s_umount temporarily. This is safe
+ * as we're holding an active reference.
+ */
+ up_write(&s->s_umount);
close_bdev_exclusive(bdev, mode);
+ down_write(&s->s_umount);
} else {
char b[BDEVNAME_SIZE];
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] vfs: don't hold s_umount over close_bdev_exclusive() call
2010-05-22 14:52 ` [PATCH] vfs: don't hold s_umount over close_bdev_exclusive() call Tejun Heo
@ 2010-05-25 8:30 ` Jens Axboe
2010-05-27 4:45 ` Al Viro
0 siblings, 1 reply; 7+ messages in thread
From: Jens Axboe @ 2010-05-25 8:30 UTC (permalink / raw)
To: Tejun Heo; +Cc: Andrew Morton, Ciprian Docan, linux-kernel, Al Viro
On Sat, May 22 2010, Tejun Heo wrote:
> This patch fixes an obscure AB-BA deadlock in get_sb_bdev().
>
> When a superblock is mounted more than once get_sb_bdev() calls
> close_bdev_exclusive() to drop the extra bdev reference while holding
> s_umount. However, sb->s_umount nests inside bd_mutex during
> __invalidate_device() and close_bdev_exclusive() acquires bd_mutex
> during blkdev_put(); thus creating an AB-BA deadlock.
>
> This condition doesn't trigger frequently. For this condition to be
> visible to lockdep, the filesystem must occupy the whole device (as
> __invalidate_device() only grabs bd_mutex for the whole device), the
> FS must be mounted more than once and partition rescan should be
> issued while the FS is still mounted.
>
> Fix it by dropping s_umount over close_bdev_exclusive().
Looks safe to me, since it has (as you note) an elevated ref count.
Acked-by: Jens Axboe <jens.axboe@oracle.com>
--
Jens Axboe
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] vfs: don't hold s_umount over close_bdev_exclusive() call
2010-05-25 8:30 ` Jens Axboe
@ 2010-05-27 4:45 ` Al Viro
0 siblings, 0 replies; 7+ messages in thread
From: Al Viro @ 2010-05-27 4:45 UTC (permalink / raw)
To: Jens Axboe; +Cc: Tejun Heo, Andrew Morton, Ciprian Docan, linux-kernel
On Tue, May 25, 2010 at 10:30:03AM +0200, Jens Axboe wrote:
> On Sat, May 22 2010, Tejun Heo wrote:
> > This patch fixes an obscure AB-BA deadlock in get_sb_bdev().
> >
> > When a superblock is mounted more than once get_sb_bdev() calls
> > close_bdev_exclusive() to drop the extra bdev reference while holding
> > s_umount. However, sb->s_umount nests inside bd_mutex during
> > __invalidate_device() and close_bdev_exclusive() acquires bd_mutex
> > during blkdev_put(); thus creating an AB-BA deadlock.
> >
> > This condition doesn't trigger frequently. For this condition to be
> > visible to lockdep, the filesystem must occupy the whole device (as
> > __invalidate_device() only grabs bd_mutex for the whole device), the
> > FS must be mounted more than once and partition rescan should be
> > issued while the FS is still mounted.
> >
> > Fix it by dropping s_umount over close_bdev_exclusive().
>
> Looks safe to me, since it has (as you note) an elevated ref count.
Ehh... It's probably OK, but I'm worried about the interplay with
->bd_fsfreeze_mutex logics there ;-/
^ permalink raw reply [flat|nested] 7+ messages in thread
* possible circular locking dependency detected
@ 2015-03-11 12:52 Daniel Wagner
0 siblings, 0 replies; 7+ messages in thread
From: Daniel Wagner @ 2015-03-11 12:52 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-kernel@vger.kernel.org
Hi,
I am seeing this info when I boot up my kvm guest. I think I haven't
seen any reports on this one. In case I missed the report, sorry about
the noise.
[ 92.867888] ======================================================
[ 92.868440] [ INFO: possible circular locking dependency detected ]
[ 92.868591] 4.0.0-rc3 #1 Not tainted
[ 92.868591] -------------------------------------------------------
[ 92.868591] sulogin/1617 is trying to acquire lock:
[ 92.868591] (&isec->lock){+.+.+.}, at: [<ffffffff8149e185>] inode_doinit_with_dentry+0xa5/0x680
[ 92.868591]
[ 92.868591] but task is already holding lock:
[ 92.868591] (&mm->mmap_sem){++++++}, at: [<ffffffff8118635f>] vm_mmap_pgoff+0x6f/0xc0
[ 92.868591]
[ 92.868591] which lock already depends on the new lock.
[ 92.868591]
[ 92.868591]
[ 92.868591] the existing dependency chain (in reverse order) is:
[ 92.868591]
-> #2 (&mm->mmap_sem){++++++}:
[ 92.868591] [<ffffffff810a7ae5>] lock_acquire+0xd5/0x2a0
[ 92.868591] [<ffffffff8119879c>] might_fault+0x8c/0xb0
[ 92.868591] [<ffffffff811e6832>] filldir+0x92/0x120
[ 92.868591] [<ffffffff8138880b>] xfs_dir2_block_getdents.isra.12+0x19b/0x1f0
[ 92.868591] [<ffffffff81388994>] xfs_readdir+0x134/0x2f0
[ 92.868591] [<ffffffff8138b78b>] xfs_file_readdir+0x2b/0x30
[ 92.868591] [<ffffffff811e660a>] iterate_dir+0x9a/0x140
[ 92.868591] [<ffffffff811e6af1>] SyS_getdents+0x81/0x100
[ 92.868591] [<ffffffff81b5cfb2>] system_call_fastpath+0x12/0x17
[ 92.868591]
-> #1 (&xfs_dir_ilock_class){++++.+}:
[ 92.868591] [<ffffffff810a7ae5>] lock_acquire+0xd5/0x2a0
[ 92.868591] [<ffffffff8109feb7>] down_read_nested+0x57/0xa0
[ 92.868591] [<ffffffff8139b612>] xfs_ilock+0x92/0x290
[ 92.868591] [<ffffffff8139b888>] xfs_ilock_attr_map_shared+0x38/0x50
[ 92.868591] [<ffffffff8133c081>] xfs_attr_get+0xc1/0x180
[ 92.868591] [<ffffffff813aa9d7>] xfs_xattr_get+0x37/0x50
[ 92.868591] [<ffffffff811fb21f>] generic_getxattr+0x4f/0x70
[ 92.868591] [<ffffffff8149e232>] inode_doinit_with_dentry+0x152/0x680
[ 92.868591] [<ffffffff8149e83b>] sb_finish_set_opts+0xdb/0x260
[ 92.868591] [<ffffffff8149ec84>] selinux_set_mnt_opts+0x2c4/0x600
[ 92.868591] [<ffffffff8149f024>] superblock_doinit+0x64/0xd0
[ 92.868591] [<ffffffff8149f0a0>] delayed_superblock_init+0x10/0x20
[ 92.868591] [<ffffffff811d2d52>] iterate_supers+0xb2/0x110
[ 92.868591] [<ffffffff8149f333>] selinux_complete_init+0x33/0x40
[ 92.868591] [<ffffffff814aea46>] security_load_policy+0xf6/0x560
[ 92.868591] [<ffffffff814a0d42>] sel_write_load+0xa2/0x740
[ 92.868591] [<ffffffff811cf92a>] vfs_write+0xba/0x200
[ 92.868591] [<ffffffff811d00a9>] SyS_write+0x49/0xb0
[ 92.868591] [<ffffffff81b5cfb2>] system_call_fastpath+0x12/0x17
[ 92.868591]
-> #0 (&isec->lock){+.+.+.}:
[ 92.868591] [<ffffffff810a6a4e>] __lock_acquire+0x1ede/0x1ee0
[ 92.868591] [<ffffffff810a7ae5>] lock_acquire+0xd5/0x2a0
[ 92.868591] [<ffffffff81b588be>] mutex_lock_nested+0x6e/0x3f0
[ 92.868591] [<ffffffff8149e185>] inode_doinit_with_dentry+0xa5/0x680
[ 92.868591] [<ffffffff8149f2fc>] selinux_d_instantiate+0x1c/0x20
[ 92.868591] [<ffffffff81491b4b>] security_d_instantiate+0x1b/0x30
[ 92.868591] [<ffffffff811e9f74>] d_instantiate+0x54/0x80
[ 92.868591] [<ffffffff8118215d>] __shmem_file_setup+0xcd/0x230
[ 92.868591] [<ffffffff81185e28>] shmem_zero_setup+0x28/0x70
[ 92.868591] [<ffffffff811a2408>] mmap_region+0x5d8/0x5f0
[ 92.868591] [<ffffffff811a273b>] do_mmap_pgoff+0x31b/0x400
[ 92.868591] [<ffffffff81186380>] vm_mmap_pgoff+0x90/0xc0
[ 92.868591] [<ffffffff811a0ae6>] SyS_mmap_pgoff+0x106/0x290
[ 92.868591] [<ffffffff81008a22>] SyS_mmap+0x22/0x30
[ 92.868591] [<ffffffff81b5cfb2>] system_call_fastpath+0x12/0x17
[ 92.868591]
[ 92.868591] other info that might help us debug this:
[ 92.868591]
[ 92.868591] Chain exists of:
&isec->lock --> &xfs_dir_ilock_class --> &mm->mmap_sem
[ 92.868591] Possible unsafe locking scenario:
[ 92.868591]
[ 92.868591] CPU0 CPU1
[ 92.868591] ---- ----
[ 92.868591] lock(&mm->mmap_sem);
[ 92.868591] lock(&xfs_dir_ilock_class);
[ 92.868591] lock(&mm->mmap_sem);
[ 92.868591] lock(&isec->lock);
[ 92.868591]
[ 92.868591] *** DEADLOCK ***
[ 92.868591]
[ 92.868591] 1 lock held by sulogin/1617:
[ 92.868591] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff8118635f>] vm_mmap_pgoff+0x6f/0xc0
[ 92.868591]
[ 92.868591] stack backtrace:
[ 92.868591] CPU: 0 PID: 1617 Comm: sulogin Not tainted 4.0.0-rc3 #1
[ 92.868591] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153950- 04/01/2014
[ 92.868591] ffffffff82e6e980 ffff880078d279f8 ffffffff81b508c5 0000000000000007
[ 92.868591] ffffffff82e31af0 ffff880078d27a48 ffffffff810a30bd ffff880078fd87a0
[ 92.868591] ffff880078d27ac8 ffff880078d27a48 ffff880078fd8000 0000000000000001
[ 92.868591] Call Trace:
[ 92.868591] [<ffffffff81b508c5>] dump_stack+0x4c/0x65
[ 92.868591] [<ffffffff810a30bd>] print_circular_bug+0x1cd/0x230
[ 92.868591] [<ffffffff810a6a4e>] __lock_acquire+0x1ede/0x1ee0
[ 92.868591] [<ffffffff810a0be5>] ? __bfs+0x105/0x240
[ 92.868591] [<ffffffff810a7ae5>] lock_acquire+0xd5/0x2a0
[ 92.868591] [<ffffffff8149e185>] ? inode_doinit_with_dentry+0xa5/0x680
[ 92.868591] [<ffffffff81b588be>] mutex_lock_nested+0x6e/0x3f0
[ 92.868591] [<ffffffff8149e185>] ? inode_doinit_with_dentry+0xa5/0x680
[ 92.868591] [<ffffffff811e9ef5>] ? __d_instantiate+0xd5/0x100
[ 92.868591] [<ffffffff8149e185>] ? inode_doinit_with_dentry+0xa5/0x680
[ 92.868591] [<ffffffff811e9f69>] ? d_instantiate+0x49/0x80
[ 92.868591] [<ffffffff8149e185>] inode_doinit_with_dentry+0xa5/0x680
[ 92.868591] [<ffffffff811e9f69>] ? d_instantiate+0x49/0x80
[ 92.868591] [<ffffffff8149f2fc>] selinux_d_instantiate+0x1c/0x20
[ 92.868591] [<ffffffff81491b4b>] security_d_instantiate+0x1b/0x30
[ 92.868591] [<ffffffff811e9f74>] d_instantiate+0x54/0x80
[ 92.868591] [<ffffffff8118215d>] __shmem_file_setup+0xcd/0x230
[ 92.868591] [<ffffffff81185e28>] shmem_zero_setup+0x28/0x70
[ 92.868591] [<ffffffff811a2408>] mmap_region+0x5d8/0x5f0
[ 92.868591] [<ffffffff811a273b>] do_mmap_pgoff+0x31b/0x400
[ 92.868591] [<ffffffff8118635f>] ? vm_mmap_pgoff+0x6f/0xc0
[ 92.868591] [<ffffffff81186380>] vm_mmap_pgoff+0x90/0xc0
[ 92.868591] [<ffffffff811a0ae6>] SyS_mmap_pgoff+0x106/0x290
[ 92.868591] [<ffffffff81507bfb>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 92.868591] [<ffffffff81008a22>] SyS_mmap+0x22/0x30
[ 92.868591] [<ffffffff81b5cfb2>] system_call_fastpath+0x12/0x17
cheers,
daniel
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-03-11 12:52 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-20 16:34 possible circular locking dependency detected Ciprian Docan
2010-05-21 21:14 ` Andrew Morton
2010-05-22 14:52 ` [PATCH] vfs: don't hold s_umount over close_bdev_exclusive() call Tejun Heo
2010-05-25 8:30 ` Jens Axboe
2010-05-27 4:45 ` Al Viro
-- strict thread matches above, loose matches on Subject: below --
2015-03-11 12:52 possible circular locking dependency detected Daniel Wagner
2007-05-13 18:11 Marko Macek
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).