linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 20090529: sysfs/reiserfs: possible circular locking dependency
@ 2009-05-30 15:33 Alexander Beregalov
  2009-05-30 15:56 ` Greg KH
  2009-05-30 19:45 ` Frederic Weisbecker
  0 siblings, 2 replies; 4+ messages in thread
From: Alexander Beregalov @ 2009-05-30 15:33 UTC (permalink / raw)
  To: linux-next, Greg Kroah-Hartman, Frederic Weisbecker

Hi

Here is a boot process.

udev: starting version 141
[ INFO: possible circular locking dependency detected ]
2.6.30-rc7-next-20090529-06589-g7701864 #6
-------------------------------------------------------
udevadm/708 is trying to acquire lock:
 (&mm->mmap_sem){++++++}, at: [<c0175962>] might_fault+0x52/0xa0

but task is already holding lock:
 (sysfs_mutex){+.+.+.}, at: [<c01d05e6>] sysfs_readdir+0x56/0x200

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #3 (sysfs_mutex){+.+.+.}:
       [<c01503da>] __lock_acquire+0xcca/0x10b0
       [<c0150834>] lock_acquire+0x74/0x90
       [<c044f860>] __mutex_lock_common+0x50/0x430
       [<c044fcf3>] mutex_lock_nested+0x33/0x40
       [<c01d0a1c>] sysfs_addrm_start+0x2c/0xb0
       [<c01d15b0>] create_dir+0x40/0x80
       [<c01d161b>] sysfs_create_dir+0x2b/0x50
       [<c02c7bc1>] kobject_add_internal+0xc1/0x220
       [<c02c7e21>] kobject_add_varg+0x31/0x50
       [<c02c7e9c>] kobject_add+0x2c/0x60
       [<c033c321>] device_add+0xf1/0x560
       [<c01ce485>] add_partition+0x135/0x240
       [<c01ceb7f>] rescan_partitions+0x23f/0x320
       [<c01b3103>] __blkdev_get+0x153/0x330
       [<c01b32ea>] blkdev_get+0xa/0x10
       [<c01ce32a>] register_disk+0x10a/0x130
       [<c02c1e09>] add_disk+0xd9/0x130
       [<c03531ca>] sd_probe_async+0x19a/0x280
       [<c01444b0>] async_thread+0xd0/0x230
       [<c013e3f3>] kthread+0x43/0x80
       [<c0103677>] kernel_thread_helper+0x7/0x10
       [<ffffffff>] 0xffffffff

-> #2 (&bdev->bd_mutex){+.+.+.}:
       [<c01503da>] __lock_acquire+0xcca/0x10b0
       [<c0150834>] lock_acquire+0x74/0x90
       [<c044f860>] __mutex_lock_common+0x50/0x430
       [<c044fcf3>] mutex_lock_nested+0x33/0x40
       [<c01b2fe3>] __blkdev_get+0x33/0x330
       [<c01b32ea>] blkdev_get+0xa/0x10
       [<c01b3451>] open_by_devnum+0x21/0x50
       [<c02027ae>] journal_init+0x22e/0x19a0
       [<c01ee1c1>] reiserfs_fill_super+0x3b1/0x1020
       [<c018ebab>] get_sb_bdev+0x12b/0x150
       [<c01ec441>] get_super_block+0x21/0x30
       [<c018db6a>] vfs_kern_mount+0x3a/0xa0
       [<c018dc29>] do_kern_mount+0x39/0xd0
       [<c01a3cf8>] do_mount+0x3b8/0x770
       [<c01a4134>] sys_mount+0x84/0xb0
       [<c0706c5e>] mount_block_root+0xd1/0x25e
       [<c0706e44>] mount_root+0x59/0x5f
       [<c0706f3a>] prepare_namespace+0xf0/0x16c
       [<c070650b>] kernel_init+0xd8/0xf1
       [<c0103677>] kernel_thread_helper+0x7/0x10
       [<ffffffff>] 0xffffffff

-> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
       [<c01503da>] __lock_acquire+0xcca/0x10b0
       [<c0150834>] lock_acquire+0x74/0x90
       [<c044f860>] __mutex_lock_common+0x50/0x430
       [<c044fcf3>] mutex_lock_nested+0x33/0x40
       [<c02072ae>] reiserfs_write_lock_once+0x1e/0x40
       [<c01e2b46>] reiserfs_get_block+0x66/0x1530
       [<c01b54d0>] do_mpage_readpage+0x340/0x490
       [<c01b5726>] mpage_readpages+0xa6/0xe0
       [<c01dff19>] reiserfs_readpages+0x19/0x20
       [<c016b21f>] __do_page_cache_readahead+0x13f/0x200
       [<c016b32e>] do_page_cache_readahead+0x4e/0x70
       [<c01647ff>] filemap_fault+0x30f/0x430
       [<c017797d>] __do_fault+0x3d/0x3a0
       [<c0178590>] handle_mm_fault+0x100/0x590
       [<c011be51>] do_page_fault+0x121/0x280
       [<c0451bfa>] error_code+0x6a/0x70
       [<c01c2fc0>] load_elf_binary+0x9d0/0x19f0
       [<c0191913>] search_binary_handler+0x163/0x2f0
       [<c0191c9d>] do_execve+0x1fd/0x270
       [<c01016de>] sys_execve+0x3e/0x70
       [<c0102ec9>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

-> #0 (&mm->mmap_sem){++++++}:
       [<c015048e>] __lock_acquire+0xd7e/0x10b0
       [<c0150834>] lock_acquire+0x74/0x90
       [<c0175993>] might_fault+0x83/0xa0
       [<c02cef26>] copy_to_user+0x36/0x130
       [<c0199a34>] filldir64+0xa4/0xf0
       [<c01d06a6>] sysfs_readdir+0x116/0x200
       [<c0199cae>] vfs_readdir+0x7e/0xa0
       [<c0199d39>] sys_getdents64+0x69/0xb0
       [<c0102e48>] sysenter_do_call+0x12/0x36
       [<ffffffff>] 0xffffffff

other info that might help us debug this:

2 locks held by udevadm/708:
 #0:  (&type->i_mutex_dir_key){+.+.+.}, at: [<c0199c7f>] vfs_readdir+0x4f/0xa0
 #1:  (sysfs_mutex){+.+.+.}, at: [<c01d05e6>] sysfs_readdir+0x56/0x200

stack backtrace:
Pid: 708, comm: udevadm Not tainted 2.6.30-rc7-next-20090529-06589-g7701864 #6
Call Trace:
 [<c044e812>] ? printk+0x18/0x1e
 [<c014e53c>] print_circular_bug_tail+0x8c/0xe0
 [<c014ce8b>] ? print_circular_bug_entry+0x4b/0x50
 [<c015048e>] __lock_acquire+0xd7e/0x10b0
 [<c0175962>] ? might_fault+0x52/0xa0
 [<c0150834>] lock_acquire+0x74/0x90
 [<c0175962>] ? might_fault+0x52/0xa0
 [<c0175993>] might_fault+0x83/0xa0
 [<c0175962>] ? might_fault+0x52/0xa0
 [<c02cef26>] copy_to_user+0x36/0x130
 [<c0199a34>] filldir64+0xa4/0xf0
 [<c01d06a6>] sysfs_readdir+0x116/0x200
 [<c0199990>] ? filldir64+0x0/0xf0
 [<c0199cae>] vfs_readdir+0x7e/0xa0
 [<c0199990>] ? filldir64+0x0/0xf0
 [<c0199d39>] sys_getdents64+0x69/0xb0
 [<c0102e48>] sysenter_do_call+0x12/0x36

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 20090529: sysfs/reiserfs: possible circular locking dependency
  2009-05-30 15:33 20090529: sysfs/reiserfs: possible circular locking dependency Alexander Beregalov
@ 2009-05-30 15:56 ` Greg KH
  2009-05-30 16:14   ` Frederic Weisbecker
  2009-05-30 19:45 ` Frederic Weisbecker
  1 sibling, 1 reply; 4+ messages in thread
From: Greg KH @ 2009-05-30 15:56 UTC (permalink / raw)
  To: Alexander Beregalov; +Cc: linux-next, Frederic Weisbecker

On Sat, May 30, 2009 at 07:33:03PM +0400, Alexander Beregalov wrote:
> Hi
> 
> Here is a boot process.
> 
> udev: starting version 141
> [ INFO: possible circular locking dependency detected ]
> 2.6.30-rc7-next-20090529-06589-g7701864 #6

Is this a new thing?  I have not changed any sysfs code in -next in a
while.  Has there been any reiserfs changes?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 20090529: sysfs/reiserfs: possible circular locking dependency
  2009-05-30 15:56 ` Greg KH
@ 2009-05-30 16:14   ` Frederic Weisbecker
  0 siblings, 0 replies; 4+ messages in thread
From: Frederic Weisbecker @ 2009-05-30 16:14 UTC (permalink / raw)
  To: Greg KH; +Cc: Alexander Beregalov, linux-next

On Sat, May 30, 2009 at 08:56:41AM -0700, Greg KH wrote:
> On Sat, May 30, 2009 at 07:33:03PM +0400, Alexander Beregalov wrote:
> > Hi
> > 
> > Here is a boot process.
> > 
> > udev: starting version 141
> > [ INFO: possible circular locking dependency detected ]
> > 2.6.30-rc7-next-20090529-06589-g7701864 #6
> 
> Is this a new thing?  I have not changed any sysfs code in -next in a
> while.  Has there been any reiserfs changes?


Hm, may be yes. I will have a close look at it.

Thanks.


> 
> thanks,
> 
> greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 20090529: sysfs/reiserfs: possible circular locking dependency
  2009-05-30 15:33 20090529: sysfs/reiserfs: possible circular locking dependency Alexander Beregalov
  2009-05-30 15:56 ` Greg KH
@ 2009-05-30 19:45 ` Frederic Weisbecker
  1 sibling, 0 replies; 4+ messages in thread
From: Frederic Weisbecker @ 2009-05-30 19:45 UTC (permalink / raw)
  To: Alexander Beregalov; +Cc: linux-next, Greg Kroah-Hartman

On Sat, May 30, 2009 at 07:33:03PM +0400, Alexander Beregalov wrote:
> Hi
> 
> Here is a boot process.
> 
> udev: starting version 141
> [ INFO: possible circular locking dependency detected ]
> 2.6.30-rc7-next-20090529-06589-g7701864 #6
> -------------------------------------------------------
> udevadm/708 is trying to acquire lock:
>  (&mm->mmap_sem){++++++}, at: [<c0175962>] might_fault+0x52/0xa0
> 
> but task is already holding lock:
>  (sysfs_mutex){+.+.+.}, at: [<c01d05e6>] sysfs_readdir+0x56/0x200
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #3 (sysfs_mutex){+.+.+.}:
> 
> -> #2 (&bdev->bd_mutex){+.+.+.}:
> 
> -> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
> 
> -> #0 (&mm->mmap_sem){++++++}:


I don't understand how it is possible to get the sysfs_mutex
from reiserfs code...
And lockdep backtraces are not very clear...


 
> other info that might help us debug this:
> 
> 2 locks held by udevadm/708:
>  #0:  (&type->i_mutex_dir_key){+.+.+.}, at: [<c0199c7f>] vfs_readdir+0x4f/0xa0
>  #1:  (sysfs_mutex){+.+.+.}, at: [<c01d05e6>] sysfs_readdir+0x56/0x200
> 
> stack backtrace:
> Pid: 708, comm: udevadm Not tainted 2.6.30-rc7-next-20090529-06589-g7701864 #6
> Call Trace:
>  [<c044e812>] ? printk+0x18/0x1e
>  [<c014e53c>] print_circular_bug_tail+0x8c/0xe0
>  [<c014ce8b>] ? print_circular_bug_entry+0x4b/0x50
>  [<c015048e>] __lock_acquire+0xd7e/0x10b0
>  [<c0175962>] ? might_fault+0x52/0xa0
>  [<c0150834>] lock_acquire+0x74/0x90
>  [<c0175962>] ? might_fault+0x52/0xa0
>  [<c0175993>] might_fault+0x83/0xa0
>  [<c0175962>] ? might_fault+0x52/0xa0
>  [<c02cef26>] copy_to_user+0x36/0x130
>  [<c0199a34>] filldir64+0xa4/0xf0
>  [<c01d06a6>] sysfs_readdir+0x116/0x200
>  [<c0199990>] ? filldir64+0x0/0xf0
>  [<c0199cae>] vfs_readdir+0x7e/0xa0
>  [<c0199990>] ? filldir64+0x0/0xf0
>  [<c0199d39>] sys_getdents64+0x69/0xb0
>  [<c0102e48>] sysenter_do_call+0x12/0x36

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-05-30 19:45 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-30 15:33 20090529: sysfs/reiserfs: possible circular locking dependency Alexander Beregalov
2009-05-30 15:56 ` Greg KH
2009-05-30 16:14   ` Frederic Weisbecker
2009-05-30 19:45 ` Frederic Weisbecker

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