LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* 2.6.21 reiserfs -- cicular locking?
@ 2007-04-26 23:40 David Brownell
  2007-04-27  5:44 ` Andrew Morton
  0 siblings, 1 reply; 10+ messages in thread
From: David Brownell @ 2007-04-26 23:40 UTC (permalink / raw)
  To: Linux Kernel list

This might be a Heisenberg, but I figure it's worth posting
in case anyone else sees similar oddness.  Never seen it
before or since.  It's as if a gremlin got annoyed with me
for switching a filesystem from reiser to ext3.  :)

- Dave


=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.21-git #6
-------------------------------------------------------
vi/4556 is trying to acquire lock:
 (&REISERFS_SB(s)->xattr_dir_sem){..--}, at: [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128

but task is already holding lock:
 (&inode->i_mutex){--..}, at: [<ffffffff8026c4fa>] chown_common+0x93/0xb3

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&inode->i_mutex){--..}:
       [<ffffffff802405f4>] __lock_acquire+0x9f7/0xbaa
       [<ffffffff802ca1ac>] get_xa_root+0x49/0x107
       [<ffffffff80240822>] lock_acquire+0x7b/0x9f
       [<ffffffff802ca1ac>] get_xa_root+0x49/0x107
       [<ffffffff8023dee0>] save_trace+0x40/0x9e
       [<ffffffff8041e1db>] __mutex_lock_slowpath+0xd8/0x281
       [<ffffffff8041ff18>] _spin_unlock_irq+0x24/0x4a
       [<ffffffff802ca1ac>] get_xa_root+0x49/0x107
       [<ffffffff802ca2a8>] open_xa_dir+0x1c/0xf8
       [<ffffffff8041f34b>] __down_read+0x34/0x9d
       [<ffffffff802cb50a>] reiserfs_delete_xattrs+0x64/0x185
       [<ffffffff802fd620>] _atomic_dec_and_lock+0x14/0x34
       [<ffffffff802b252e>] reiserfs_delete_inode+0x38/0xae
       [<ffffffff8027f6bc>] generic_delete_inode+0x64/0xf5
       [<ffffffff802b24f6>] reiserfs_delete_inode+0x0/0xae
       [<ffffffff8027f6d2>] generic_delete_inode+0x7a/0xf5
       [<ffffffff80276b95>] do_unlinkat+0xd9/0x14f
       [<ffffffff8023f75f>] trace_hardirqs_on+0x123/0x14d
       [<ffffffff8041f4d1>] trace_hardirqs_on_thunk+0x35/0x37
       [<ffffffff8020954e>] system_call+0x7e/0x83
       [<ffffffffffffffff>] 0xffffffffffffffff

-> #0 (&REISERFS_SB(s)->xattr_dir_sem){..--}:
       [<ffffffff8023ee6f>] print_circular_bug_header+0xcc/0xd3
       [<ffffffff802404f0>] __lock_acquire+0x8f3/0xbaa
       [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
       [<ffffffff80240822>] lock_acquire+0x7b/0x9f
       [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
       [<ffffffff8023bb03>] down_read+0x32/0x3b
       [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
       [<ffffffff8022e285>] __capable+0x9/0x1d
       [<ffffffff802b2828>] reiserfs_setattr+0x11e/0x1ec
       [<ffffffff8022bd6b>] current_fs_time+0x35/0x3a
       [<ffffffff802803a1>] notify_change+0x122/0x231
       [<ffffffff8026c505>] chown_common+0x9e/0xb3
       [<ffffffff8026e7a6>] fget+0x88/0xa7
       [<ffffffff8026c54a>] sys_fchown+0x30/0x47
       [<ffffffff8020954e>] system_call+0x7e/0x83
       [<ffffffffffffffff>] 0xffffffffffffffff

other info that might help us debug this:

1 lock held by vi/4556:
 #0:  (&inode->i_mutex){--..}, at: [<ffffffff8026c4fa>] chown_common+0x93/0xb3

stack backtrace:

Call Trace:
 [<ffffffff8023eacc>] print_circular_bug_tail+0x69/0x72
 [<ffffffff8023ee6f>] print_circular_bug_header+0xcc/0xd3
 [<ffffffff802404f0>] __lock_acquire+0x8f3/0xbaa
 [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
 [<ffffffff80240822>] lock_acquire+0x7b/0x9f
 [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
 [<ffffffff8023bb03>] down_read+0x32/0x3b
 [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
 [<ffffffff8022e285>] __capable+0x9/0x1d
 [<ffffffff802b2828>] reiserfs_setattr+0x11e/0x1ec
 [<ffffffff8022bd6b>] current_fs_time+0x35/0x3a
 [<ffffffff802803a1>] notify_change+0x122/0x231
 [<ffffffff8026c505>] chown_common+0x9e/0xb3
 [<ffffffff8026e7a6>] fget+0x88/0xa7
 [<ffffffff8026c54a>] sys_fchown+0x30/0x47
 [<ffffffff8020954e>] system_call+0x7e/0x83


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

* Re: 2.6.21 reiserfs -- cicular locking?
  2007-04-26 23:40 2.6.21 reiserfs -- cicular locking? David Brownell
@ 2007-04-27  5:44 ` Andrew Morton
  2007-04-27 10:09   ` Takashi Iwai
  0 siblings, 1 reply; 10+ messages in thread
From: Andrew Morton @ 2007-04-27  5:44 UTC (permalink / raw)
  To: David Brownell; +Cc: Linux Kernel list, reiserfs-dev

On Thu, 26 Apr 2007 16:40:14 -0700 David Brownell <david-b@pacbell.net> wrote:

> This might be a Heisenberg, but I figure it's worth posting
> in case anyone else sees similar oddness.  Never seen it
> before or since.  It's as if a gremlin got annoyed with me
> for switching a filesystem from reiser to ext3.  :)
> 
> - Dave
> 
> 
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.21-git #6
> -------------------------------------------------------
> vi/4556 is trying to acquire lock:
>  (&REISERFS_SB(s)->xattr_dir_sem){..--}, at: [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
> 
> but task is already holding lock:
>  (&inode->i_mutex){--..}, at: [<ffffffff8026c4fa>] chown_common+0x93/0xb3
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #1 (&inode->i_mutex){--..}:
>        [<ffffffff802405f4>] __lock_acquire+0x9f7/0xbaa
>        [<ffffffff802ca1ac>] get_xa_root+0x49/0x107
>        [<ffffffff80240822>] lock_acquire+0x7b/0x9f
>        [<ffffffff802ca1ac>] get_xa_root+0x49/0x107
>        [<ffffffff8023dee0>] save_trace+0x40/0x9e
>        [<ffffffff8041e1db>] __mutex_lock_slowpath+0xd8/0x281
>        [<ffffffff8041ff18>] _spin_unlock_irq+0x24/0x4a
>        [<ffffffff802ca1ac>] get_xa_root+0x49/0x107
>        [<ffffffff802ca2a8>] open_xa_dir+0x1c/0xf8
>        [<ffffffff8041f34b>] __down_read+0x34/0x9d
>        [<ffffffff802cb50a>] reiserfs_delete_xattrs+0x64/0x185
>        [<ffffffff802fd620>] _atomic_dec_and_lock+0x14/0x34
>        [<ffffffff802b252e>] reiserfs_delete_inode+0x38/0xae
>        [<ffffffff8027f6bc>] generic_delete_inode+0x64/0xf5
>        [<ffffffff802b24f6>] reiserfs_delete_inode+0x0/0xae
>        [<ffffffff8027f6d2>] generic_delete_inode+0x7a/0xf5
>        [<ffffffff80276b95>] do_unlinkat+0xd9/0x14f
>        [<ffffffff8023f75f>] trace_hardirqs_on+0x123/0x14d
>        [<ffffffff8041f4d1>] trace_hardirqs_on_thunk+0x35/0x37
>        [<ffffffff8020954e>] system_call+0x7e/0x83
>        [<ffffffffffffffff>] 0xffffffffffffffff
> 
> -> #0 (&REISERFS_SB(s)->xattr_dir_sem){..--}:
>        [<ffffffff8023ee6f>] print_circular_bug_header+0xcc/0xd3
>        [<ffffffff802404f0>] __lock_acquire+0x8f3/0xbaa
>        [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
>        [<ffffffff80240822>] lock_acquire+0x7b/0x9f
>        [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
>        [<ffffffff8023bb03>] down_read+0x32/0x3b
>        [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
>        [<ffffffff8022e285>] __capable+0x9/0x1d
>        [<ffffffff802b2828>] reiserfs_setattr+0x11e/0x1ec
>        [<ffffffff8022bd6b>] current_fs_time+0x35/0x3a
>        [<ffffffff802803a1>] notify_change+0x122/0x231
>        [<ffffffff8026c505>] chown_common+0x9e/0xb3
>        [<ffffffff8026e7a6>] fget+0x88/0xa7
>        [<ffffffff8026c54a>] sys_fchown+0x30/0x47
>        [<ffffffff8020954e>] system_call+0x7e/0x83
>        [<ffffffffffffffff>] 0xffffffffffffffff
> 
> other info that might help us debug this:
> 
> 1 lock held by vi/4556:
>  #0:  (&inode->i_mutex){--..}, at: [<ffffffff8026c4fa>] chown_common+0x93/0xb3
> 
> stack backtrace:
> 
> Call Trace:
>  [<ffffffff8023eacc>] print_circular_bug_tail+0x69/0x72
>  [<ffffffff8023ee6f>] print_circular_bug_header+0xcc/0xd3
>  [<ffffffff802404f0>] __lock_acquire+0x8f3/0xbaa
>  [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
>  [<ffffffff80240822>] lock_acquire+0x7b/0x9f
>  [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
>  [<ffffffff8023bb03>] down_read+0x32/0x3b
>  [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
>  [<ffffffff8022e285>] __capable+0x9/0x1d
>  [<ffffffff802b2828>] reiserfs_setattr+0x11e/0x1ec
>  [<ffffffff8022bd6b>] current_fs_time+0x35/0x3a
>  [<ffffffff802803a1>] notify_change+0x122/0x231
>  [<ffffffff8026c505>] chown_common+0x9e/0xb3
>  [<ffffffff8026e7a6>] fget+0x88/0xa7
>  [<ffffffff8026c54a>] sys_fchown+0x30/0x47
>  [<ffffffff8020954e>] system_call+0x7e/0x83
> 

cc added.  This was also reported againt -rc7-mm1 (or 2)

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

* Re: 2.6.21 reiserfs -- cicular locking?
  2007-04-27  5:44 ` Andrew Morton
@ 2007-04-27 10:09   ` Takashi Iwai
  2007-04-27 10:53     ` Takashi Iwai
  0 siblings, 1 reply; 10+ messages in thread
From: Takashi Iwai @ 2007-04-27 10:09 UTC (permalink / raw)
  To: Andrew Morton; +Cc: David Brownell, Linux Kernel list, reiserfs-dev

At Thu, 26 Apr 2007 22:44:08 -0700,
Andrew Morton wrote:
> 
> On Thu, 26 Apr 2007 16:40:14 -0700 David Brownell <david-b@pacbell.net> wrote:
> 
> > This might be a Heisenberg, but I figure it's worth posting
> > in case anyone else sees similar oddness.  Never seen it
> > before or since.  It's as if a gremlin got annoyed with me
> > for switching a filesystem from reiser to ext3.  :)
> > 
> > - Dave
> > 
> > 
> > =======================================================
> > [ INFO: possible circular locking dependency detected ]
> > 2.6.21-git #6
> > -------------------------------------------------------
> > vi/4556 is trying to acquire lock:
> >  (&REISERFS_SB(s)->xattr_dir_sem){..--}, at: [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
> > 
> > but task is already holding lock:
> >  (&inode->i_mutex){--..}, at: [<ffffffff8026c4fa>] chown_common+0x93/0xb3
> > 
> > which lock already depends on the new lock.
> > 
> > 
> > the existing dependency chain (in reverse order) is:
> > 
> > -> #1 (&inode->i_mutex){--..}:
> >        [<ffffffff802405f4>] __lock_acquire+0x9f7/0xbaa
> >        [<ffffffff802ca1ac>] get_xa_root+0x49/0x107
> >        [<ffffffff80240822>] lock_acquire+0x7b/0x9f
> >        [<ffffffff802ca1ac>] get_xa_root+0x49/0x107
> >        [<ffffffff8023dee0>] save_trace+0x40/0x9e
> >        [<ffffffff8041e1db>] __mutex_lock_slowpath+0xd8/0x281
> >        [<ffffffff8041ff18>] _spin_unlock_irq+0x24/0x4a
> >        [<ffffffff802ca1ac>] get_xa_root+0x49/0x107
> >        [<ffffffff802ca2a8>] open_xa_dir+0x1c/0xf8
> >        [<ffffffff8041f34b>] __down_read+0x34/0x9d
> >        [<ffffffff802cb50a>] reiserfs_delete_xattrs+0x64/0x185
> >        [<ffffffff802fd620>] _atomic_dec_and_lock+0x14/0x34
> >        [<ffffffff802b252e>] reiserfs_delete_inode+0x38/0xae
> >        [<ffffffff8027f6bc>] generic_delete_inode+0x64/0xf5
> >        [<ffffffff802b24f6>] reiserfs_delete_inode+0x0/0xae
> >        [<ffffffff8027f6d2>] generic_delete_inode+0x7a/0xf5
> >        [<ffffffff80276b95>] do_unlinkat+0xd9/0x14f
> >        [<ffffffff8023f75f>] trace_hardirqs_on+0x123/0x14d
> >        [<ffffffff8041f4d1>] trace_hardirqs_on_thunk+0x35/0x37
> >        [<ffffffff8020954e>] system_call+0x7e/0x83
> >        [<ffffffffffffffff>] 0xffffffffffffffff
> > 
> > -> #0 (&REISERFS_SB(s)->xattr_dir_sem){..--}:
> >        [<ffffffff8023ee6f>] print_circular_bug_header+0xcc/0xd3
> >        [<ffffffff802404f0>] __lock_acquire+0x8f3/0xbaa
> >        [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
> >        [<ffffffff80240822>] lock_acquire+0x7b/0x9f
> >        [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
> >        [<ffffffff8023bb03>] down_read+0x32/0x3b
> >        [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
> >        [<ffffffff8022e285>] __capable+0x9/0x1d
> >        [<ffffffff802b2828>] reiserfs_setattr+0x11e/0x1ec
> >        [<ffffffff8022bd6b>] current_fs_time+0x35/0x3a
> >        [<ffffffff802803a1>] notify_change+0x122/0x231
> >        [<ffffffff8026c505>] chown_common+0x9e/0xb3
> >        [<ffffffff8026e7a6>] fget+0x88/0xa7
> >        [<ffffffff8026c54a>] sys_fchown+0x30/0x47
> >        [<ffffffff8020954e>] system_call+0x7e/0x83
> >        [<ffffffffffffffff>] 0xffffffffffffffff
> > 
> > other info that might help us debug this:
> > 
> > 1 lock held by vi/4556:
> >  #0:  (&inode->i_mutex){--..}, at: [<ffffffff8026c4fa>] chown_common+0x93/0xb3
> > 
> > stack backtrace:
> > 
> > Call Trace:
> >  [<ffffffff8023eacc>] print_circular_bug_tail+0x69/0x72
> >  [<ffffffff8023ee6f>] print_circular_bug_header+0xcc/0xd3
> >  [<ffffffff802404f0>] __lock_acquire+0x8f3/0xbaa
> >  [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
> >  [<ffffffff80240822>] lock_acquire+0x7b/0x9f
> >  [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
> >  [<ffffffff8023bb03>] down_read+0x32/0x3b
> >  [<ffffffff802caf4b>] reiserfs_chown_xattrs+0x5b/0x128
> >  [<ffffffff8022e285>] __capable+0x9/0x1d
> >  [<ffffffff802b2828>] reiserfs_setattr+0x11e/0x1ec
> >  [<ffffffff8022bd6b>] current_fs_time+0x35/0x3a
> >  [<ffffffff802803a1>] notify_change+0x122/0x231
> >  [<ffffffff8026c505>] chown_common+0x9e/0xb3
> >  [<ffffffff8026e7a6>] fget+0x88/0xa7
> >  [<ffffffff8026c54a>] sys_fchown+0x30/0x47
> >  [<ffffffff8020954e>] system_call+0x7e/0x83
> > 
> 
> cc added.  This was also reported againt -rc7-mm1 (or 2)

I got a similar bug right now at the fresh boot of 2.6.21.


ReiserFS: sda2: found reiserfs format "3.6" with standard journal
ReiserFS: sda2: using ordered data mode
ReiserFS: sda2: journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda2: checking transaction log (sda2)
ReiserFS: sda2: Using r5 hash to sort names
ReiserFS: sda2: Removing [3613 1354701 0x0 SD]..done
ReiserFS: sda2: There were 1 uncompleted unlinks/truncates. Completed

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.21-work #1
-------------------------------------------------------
mktemp/1459 is trying to acquire lock:
 (&REISERFS_I(inode)->xattr_sem){..--}, at: [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]

but task is already holding lock:
 (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&inode->i_mutex){--..}:
       [<c0134d2e>] __lock_acquire+0xa27/0xbbb
       [<e08a2e9a>] get_xa_root+0x42/0xfc [reiserfs]
       [<c0134f29>] lock_acquire+0x67/0x81
       [<e08a2e9a>] get_xa_root+0x42/0xfc [reiserfs]
       [<c028b69d>] __mutex_lock_slowpath+0xe3/0x241
       [<e08a2e9a>] get_xa_root+0x42/0xfc [reiserfs]
       [<e08a2e9a>] get_xa_root+0x42/0xfc [reiserfs]
       [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
       [<e08a2f83>] open_xa_dir+0x16/0xd9 [reiserfs]
       [<e08a3feb>] reiserfs_delete_xattrs+0x4b/0x15b [reiserfs]
       [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
       [<c012e0d6>] down_read+0x3d/0x4e
       [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
       [<e08a3ff7>] reiserfs_delete_xattrs+0x57/0x15b [reiserfs]
       [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
       [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
       [<e088b171>] reiserfs_delete_inode+0x35/0xa1 [reiserfs]
       [<c01c0fce>] _atomic_dec_and_lock+0x2a/0x48
       [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
       [<c017507f>] generic_delete_inode+0x75/0xdd
       [<c01747c4>] iput+0x60/0x62
       [<e0892878>] finish_unfinished+0x2ee/0x350 [reiserfs]
       [<c016bc00>] lookup_one_len+0x21/0x59
       [<e08a3d45>] reiserfs_xattr_init+0x8f/0x1f6 [reiserfs]
       [<e0893cd4>] reiserfs_fill_super+0x95e/0xab6 [reiserfs]
       [<c0129520>] rcu_barrier+0x5a/0x6a
       [<c0105cd0>] dump_trace+0x89/0x93
       [<c010a075>] save_stack_trace+0x1c/0x37
       [<c01327a5>] save_trace+0x40/0x92
       [<c0165c02>] sget+0x1f/0x33b
       [<c0134e2e>] __lock_acquire+0xb27/0xbbb
       [<c0165c02>] sget+0x1f/0x33b
       [<c01c483e>] vsnprintf+0x450/0x48c
       [<c01c494c>] snprintf+0x1f/0x22
       [<c0194687>] disk_name+0x7e/0x88
       [<c016677f>] get_sb_bdev+0xe6/0x130
       [<e0891ccc>] get_super_block+0x20/0x25 [reiserfs]
       [<e0893376>] reiserfs_fill_super+0x0/0xab6 [reiserfs]
       [<c016633b>] vfs_kern_mount+0x83/0xf6
       [<c01663f0>] do_kern_mount+0x2d/0x3e
       [<c0177ee4>] do_mount+0x612/0x685
       [<c01543e9>] __handle_mm_fault+0x50c/0x902
       [<c01543b2>] __handle_mm_fault+0x4d5/0x902
       [<c028c912>] _spin_unlock+0x14/0x1c
       [<c01547a8>] __handle_mm_fault+0x8cb/0x902
       [<c014d104>] get_page_from_freelist+0x1fd/0x31d
       [<c0133eeb>] trace_hardirqs_on+0x126/0x150
       [<c012e14d>] up_read+0x14/0x27
       [<c014d28c>] __alloc_pages+0x68/0x2aa
       [<c0176899>] copy_mount_options+0x26/0x109
       [<c0177fce>] sys_mount+0x77/0xae
       [<c0104d74>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

-> #1 (&REISERFS_SB(s)->xattr_dir_sem){..--}:
       [<c0134d2e>] __lock_acquire+0xa27/0xbbb
       [<e08a3bf2>] reiserfs_listxattr+0x5a/0x11e [reiserfs]
       [<c0134f29>] lock_acquire+0x67/0x81
       [<e08a3bf2>] reiserfs_listxattr+0x5a/0x11e [reiserfs]
       [<c012e0d6>] down_read+0x3d/0x4e
       [<e08a3bf2>] reiserfs_listxattr+0x5a/0x11e [reiserfs]
       [<e08a3bf2>] reiserfs_listxattr+0x5a/0x11e [reiserfs]
       [<c0133eeb>] trace_hardirqs_on+0x126/0x150
       [<e08a3b98>] reiserfs_listxattr+0x0/0x11e [reiserfs]
       [<c017ab4f>] vfs_listxattr+0x46/0x7c
       [<c017abc9>] listxattr+0x44/0x87
       [<c017ac73>] sys_llistxattr+0x33/0x44
       [<c012e14d>] up_read+0x14/0x27
       [<c0104dbc>] restore_nocheck+0x12/0x15
       [<c0104d74>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

-> #0 (&REISERFS_I(inode)->xattr_sem){..--}:
       [<c012e6d2>] print_stack_trace+0x4e/0x5c
       [<c0134c1a>] __lock_acquire+0x913/0xbbb
       [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
       [<c017570b>] new_inode+0x24/0x8a
       [<c0134f29>] lock_acquire+0x67/0x81
       [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
       [<c012e0d6>] down_read+0x3d/0x4e
       [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
       [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
       [<e08873b5>] reiserfs_create+0x3d/0x1bc [reiserfs]
       [<e08a2e37>] reiserfs_permission+0x0/0x21 [reiserfs]
       [<c016abf2>] permission+0xc8/0xdb
       [<c016b11f>] vfs_create+0x9c/0x106
       [<c016d871>] open_namei+0x177/0x5a2
       [<c016348d>] do_filp_open+0x25/0x39
       [<c028c912>] _spin_unlock+0x14/0x1c
       [<c016325b>] get_unused_fd+0xb3/0xbd
       [<c01634e3>] do_sys_open+0x42/0xbe
       [<c0163598>] sys_open+0x1c/0x1e
       [<c0104d74>] syscall_call+0x7/0xb
       [<ffffffff>] 0xffffffff

other info that might help us debug this:

1 lock held by mktemp/1459:
 #0:  (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2

stack backtrace:
 [<c013343e>] print_circular_bug_tail+0x5f/0x67
 [<c0134c1a>] __lock_acquire+0x913/0xbbb
 [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
 [<c017570b>] new_inode+0x24/0x8a
 [<c0134f29>] lock_acquire+0x67/0x81
 [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
 [<c012e0d6>] down_read+0x3d/0x4e
 [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
 [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
 [<e08873b5>] reiserfs_create+0x3d/0x1bc [reiserfs]
 [<e08a2e37>] reiserfs_permission+0x0/0x21 [reiserfs]
 [<c016abf2>] permission+0xc8/0xdb
 [<c016b11f>] vfs_create+0x9c/0x106
 [<c016d871>] open_namei+0x177/0x5a2
 [<c016348d>] do_filp_open+0x25/0x39
 [<c028c912>] _spin_unlock+0x14/0x1c
 [<c016325b>] get_unused_fd+0xb3/0xbd
 [<c01634e3>] do_sys_open+0x42/0xbe
 [<c0163598>] sys_open+0x1c/0x1e
 [<c0104d74>] syscall_call+0x7/0xb
 =======================


Takashi

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

* Re: 2.6.21 reiserfs -- cicular locking?
  2007-04-27 10:09   ` Takashi Iwai
@ 2007-04-27 10:53     ` Takashi Iwai
  2007-04-27 11:09       ` Jeff Mahoney
  0 siblings, 1 reply; 10+ messages in thread
From: Takashi Iwai @ 2007-04-27 10:53 UTC (permalink / raw)
  To: Andrew Morton
  Cc: David Brownell, Linux Kernel list, reiserfs-dev, Jeff Mahoney

At Fri, 27 Apr 2007 12:09:03 +0200,
I wrote:
> 
> I got a similar bug right now at the fresh boot of 2.6.21.
> 
> 
> ReiserFS: sda2: found reiserfs format "3.6" with standard journal
> ReiserFS: sda2: using ordered data mode
> ReiserFS: sda2: journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
> ReiserFS: sda2: checking transaction log (sda2)
> ReiserFS: sda2: Using r5 hash to sort names
> ReiserFS: sda2: Removing [3613 1354701 0x0 SD]..done
> ReiserFS: sda2: There were 1 uncompleted unlinks/truncates. Completed
> 
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.21-work #1
> -------------------------------------------------------
> mktemp/1459 is trying to acquire lock:
>  (&REISERFS_I(inode)->xattr_sem){..--}, at: [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
> 
> but task is already holding lock:
>  (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #2 (&inode->i_mutex){--..}:
>        [<c0134d2e>] __lock_acquire+0xa27/0xbbb
>        [<e08a2e9a>] get_xa_root+0x42/0xfc [reiserfs]
>        [<c0134f29>] lock_acquire+0x67/0x81
>        [<e08a2e9a>] get_xa_root+0x42/0xfc [reiserfs]
>        [<c028b69d>] __mutex_lock_slowpath+0xe3/0x241
>        [<e08a2e9a>] get_xa_root+0x42/0xfc [reiserfs]
>        [<e08a2e9a>] get_xa_root+0x42/0xfc [reiserfs]
>        [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
>        [<e08a2f83>] open_xa_dir+0x16/0xd9 [reiserfs]
>        [<e08a3feb>] reiserfs_delete_xattrs+0x4b/0x15b [reiserfs]
>        [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
>        [<c012e0d6>] down_read+0x3d/0x4e
>        [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
>        [<e08a3ff7>] reiserfs_delete_xattrs+0x57/0x15b [reiserfs]
>        [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
>        [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
>        [<e088b171>] reiserfs_delete_inode+0x35/0xa1 [reiserfs]
>        [<c01c0fce>] _atomic_dec_and_lock+0x2a/0x48
>        [<e088b13c>] reiserfs_delete_inode+0x0/0xa1 [reiserfs]
>        [<c017507f>] generic_delete_inode+0x75/0xdd
>        [<c01747c4>] iput+0x60/0x62
>        [<e0892878>] finish_unfinished+0x2ee/0x350 [reiserfs]
>        [<c016bc00>] lookup_one_len+0x21/0x59
>        [<e08a3d45>] reiserfs_xattr_init+0x8f/0x1f6 [reiserfs]
>        [<e0893cd4>] reiserfs_fill_super+0x95e/0xab6 [reiserfs]
>        [<c0129520>] rcu_barrier+0x5a/0x6a
>        [<c0105cd0>] dump_trace+0x89/0x93
>        [<c010a075>] save_stack_trace+0x1c/0x37
>        [<c01327a5>] save_trace+0x40/0x92
>        [<c0165c02>] sget+0x1f/0x33b
>        [<c0134e2e>] __lock_acquire+0xb27/0xbbb
>        [<c0165c02>] sget+0x1f/0x33b
>        [<c01c483e>] vsnprintf+0x450/0x48c
>        [<c01c494c>] snprintf+0x1f/0x22
>        [<c0194687>] disk_name+0x7e/0x88
>        [<c016677f>] get_sb_bdev+0xe6/0x130
>        [<e0891ccc>] get_super_block+0x20/0x25 [reiserfs]
>        [<e0893376>] reiserfs_fill_super+0x0/0xab6 [reiserfs]
>        [<c016633b>] vfs_kern_mount+0x83/0xf6
>        [<c01663f0>] do_kern_mount+0x2d/0x3e
>        [<c0177ee4>] do_mount+0x612/0x685
>        [<c01543e9>] __handle_mm_fault+0x50c/0x902
>        [<c01543b2>] __handle_mm_fault+0x4d5/0x902
>        [<c028c912>] _spin_unlock+0x14/0x1c
>        [<c01547a8>] __handle_mm_fault+0x8cb/0x902
>        [<c014d104>] get_page_from_freelist+0x1fd/0x31d
>        [<c0133eeb>] trace_hardirqs_on+0x126/0x150
>        [<c012e14d>] up_read+0x14/0x27
>        [<c014d28c>] __alloc_pages+0x68/0x2aa
>        [<c0176899>] copy_mount_options+0x26/0x109
>        [<c0177fce>] sys_mount+0x77/0xae
>        [<c0104d74>] syscall_call+0x7/0xb
>        [<ffffffff>] 0xffffffff
> 
> -> #1 (&REISERFS_SB(s)->xattr_dir_sem){..--}:
>        [<c0134d2e>] __lock_acquire+0xa27/0xbbb
>        [<e08a3bf2>] reiserfs_listxattr+0x5a/0x11e [reiserfs]
>        [<c0134f29>] lock_acquire+0x67/0x81
>        [<e08a3bf2>] reiserfs_listxattr+0x5a/0x11e [reiserfs]
>        [<c012e0d6>] down_read+0x3d/0x4e
>        [<e08a3bf2>] reiserfs_listxattr+0x5a/0x11e [reiserfs]
>        [<e08a3bf2>] reiserfs_listxattr+0x5a/0x11e [reiserfs]
>        [<c0133eeb>] trace_hardirqs_on+0x126/0x150
>        [<e08a3b98>] reiserfs_listxattr+0x0/0x11e [reiserfs]
>        [<c017ab4f>] vfs_listxattr+0x46/0x7c
>        [<c017abc9>] listxattr+0x44/0x87
>        [<c017ac73>] sys_llistxattr+0x33/0x44
>        [<c012e14d>] up_read+0x14/0x27
>        [<c0104dbc>] restore_nocheck+0x12/0x15
>        [<c0104d74>] syscall_call+0x7/0xb
>        [<ffffffff>] 0xffffffff
> 
> -> #0 (&REISERFS_I(inode)->xattr_sem){..--}:
>        [<c012e6d2>] print_stack_trace+0x4e/0x5c
>        [<c0134c1a>] __lock_acquire+0x913/0xbbb
>        [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>        [<c017570b>] new_inode+0x24/0x8a
>        [<c0134f29>] lock_acquire+0x67/0x81
>        [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>        [<c012e0d6>] down_read+0x3d/0x4e
>        [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>        [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>        [<e08873b5>] reiserfs_create+0x3d/0x1bc [reiserfs]
>        [<e08a2e37>] reiserfs_permission+0x0/0x21 [reiserfs]
>        [<c016abf2>] permission+0xc8/0xdb
>        [<c016b11f>] vfs_create+0x9c/0x106
>        [<c016d871>] open_namei+0x177/0x5a2
>        [<c016348d>] do_filp_open+0x25/0x39
>        [<c028c912>] _spin_unlock+0x14/0x1c
>        [<c016325b>] get_unused_fd+0xb3/0xbd
>        [<c01634e3>] do_sys_open+0x42/0xbe
>        [<c0163598>] sys_open+0x1c/0x1e
>        [<c0104d74>] syscall_call+0x7/0xb
>        [<ffffffff>] 0xffffffff
> 
> other info that might help us debug this:
> 
> 1 lock held by mktemp/1459:
>  #0:  (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2
> 
> stack backtrace:
>  [<c013343e>] print_circular_bug_tail+0x5f/0x67
>  [<c0134c1a>] __lock_acquire+0x913/0xbbb
>  [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>  [<c017570b>] new_inode+0x24/0x8a
>  [<c0134f29>] lock_acquire+0x67/0x81
>  [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>  [<c012e0d6>] down_read+0x3d/0x4e
>  [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>  [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>  [<e08873b5>] reiserfs_create+0x3d/0x1bc [reiserfs]
>  [<e08a2e37>] reiserfs_permission+0x0/0x21 [reiserfs]
>  [<c016abf2>] permission+0xc8/0xdb
>  [<c016b11f>] vfs_create+0x9c/0x106
>  [<c016d871>] open_namei+0x177/0x5a2
>  [<c016348d>] do_filp_open+0x25/0x39
>  [<c028c912>] _spin_unlock+0x14/0x1c
>  [<c016325b>] get_unused_fd+0xb3/0xbd
>  [<c01634e3>] do_sys_open+0x42/0xbe
>  [<c0163598>] sys_open+0x1c/0x1e
>  [<c0104d74>] syscall_call+0x7/0xb
>  =======================

The message disappears when I revert the patch:

commit 9b7f375505f5611efb562065b57814b28a81abc3
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Mon Apr 23 14:41:17 2007 -0700

    reiserfs: fix xattr root locking/refcount bug
    

So, likely a newly introduced bug after rc7...


Takashi

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

* Re: 2.6.21 reiserfs -- cicular locking?
  2007-04-27 10:53     ` Takashi Iwai
@ 2007-04-27 11:09       ` Jeff Mahoney
  2007-04-27 12:20         ` Takashi Iwai
  0 siblings, 1 reply; 10+ messages in thread
From: Jeff Mahoney @ 2007-04-27 11:09 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Andrew Morton, David Brownell, Linux Kernel list, reiserfs-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Takashi Iwai wrote:
> At Fri, 27 Apr 2007 12:09:03 +0200,
> I wrote:
>> I got a similar bug right now at the fresh boot of 2.6.21.
>>
>>
>> ReiserFS: sda2: found reiserfs format "3.6" with standard journal
>> ReiserFS: sda2: using ordered data mode
>> ReiserFS: sda2: journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
>> ReiserFS: sda2: checking transaction log (sda2)
>> ReiserFS: sda2: Using r5 hash to sort names
>> ReiserFS: sda2: Removing [3613 1354701 0x0 SD]..done
>> ReiserFS: sda2: There were 1 uncompleted unlinks/truncates. Completed
>>
>> =======================================================
>> [ INFO: possible circular locking dependency detected ]
>> 2.6.21-work #1
>> -------------------------------------------------------
>> mktemp/1459 is trying to acquire lock:
>>  (&REISERFS_I(inode)->xattr_sem){..--}, at: [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>>
>> but task is already holding lock:
>>  (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2
>>
>> which lock already depends on the new lock.
> The message disappears when I revert the patch:
> 
> commit 9b7f375505f5611efb562065b57814b28a81abc3
> Author: Jeff Mahoney <jeffm@suse.com>
> Date:   Mon Apr 23 14:41:17 2007 -0700
> 
>     reiserfs: fix xattr root locking/refcount bug
>     
> 
> So, likely a newly introduced bug after rc7...

I got a message with a trace similar to this from Vladimir before I
submitted that patch. I'm not sure how to annotate this, since the
xattr_sem can never be taken in the manner described. Internal inodes
are protected by I_PRIVATE.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGMdnNLPWxlyuTD7IRApM+AJwKynnSbQfGKByzvDFs5d0OqO82ggCfVzoP
MNzGHMUQdmn2Xg31QWhB3mQ=
=A37l
-----END PGP SIGNATURE-----

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

* Re: 2.6.21 reiserfs -- cicular locking?
  2007-04-27 11:09       ` Jeff Mahoney
@ 2007-04-27 12:20         ` Takashi Iwai
  2007-04-27 15:17           ` Jeff Mahoney
  0 siblings, 1 reply; 10+ messages in thread
From: Takashi Iwai @ 2007-04-27 12:20 UTC (permalink / raw)
  To: Jeff Mahoney
  Cc: Andrew Morton, David Brownell, Linux Kernel list, reiserfs-dev

At Fri, 27 Apr 2007 07:09:01 -0400,
Jeff Mahoney wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Takashi Iwai wrote:
> > At Fri, 27 Apr 2007 12:09:03 +0200,
> > I wrote:
> >> I got a similar bug right now at the fresh boot of 2.6.21.
> >>
> >>
> >> ReiserFS: sda2: found reiserfs format "3.6" with standard journal
> >> ReiserFS: sda2: using ordered data mode
> >> ReiserFS: sda2: journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
> >> ReiserFS: sda2: checking transaction log (sda2)
> >> ReiserFS: sda2: Using r5 hash to sort names
> >> ReiserFS: sda2: Removing [3613 1354701 0x0 SD]..done
> >> ReiserFS: sda2: There were 1 uncompleted unlinks/truncates. Completed
> >>
> >> =======================================================
> >> [ INFO: possible circular locking dependency detected ]
> >> 2.6.21-work #1
> >> -------------------------------------------------------
> >> mktemp/1459 is trying to acquire lock:
> >>  (&REISERFS_I(inode)->xattr_sem){..--}, at: [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
> >>
> >> but task is already holding lock:
> >>  (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2
> >>
> >> which lock already depends on the new lock.
> > The message disappears when I revert the patch:
> > 
> > commit 9b7f375505f5611efb562065b57814b28a81abc3
> > Author: Jeff Mahoney <jeffm@suse.com>
> > Date:   Mon Apr 23 14:41:17 2007 -0700
> > 
> >     reiserfs: fix xattr root locking/refcount bug
> >     
> > 
> > So, likely a newly introduced bug after rc7...
> 
> I got a message with a trace similar to this from Vladimir before I
> submitted that patch. I'm not sure how to annotate this, since the
> xattr_sem can never be taken in the manner described. Internal inodes
> are protected by I_PRIVATE.

Hm, then maybe my case was just a coincidence.

FWIW, I can reproduce the deadlock warning at each time I boot
non-patched 2.6.21, and after reverting the patch, it disappeared.


Takashi

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

* Re: 2.6.21 reiserfs -- cicular locking?
  2007-04-27 12:20         ` Takashi Iwai
@ 2007-04-27 15:17           ` Jeff Mahoney
  2007-04-27 16:21             ` Jeff Mahoney
  0 siblings, 1 reply; 10+ messages in thread
From: Jeff Mahoney @ 2007-04-27 15:17 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Andrew Morton, David Brownell, Linux Kernel list, reiserfs-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Takashi Iwai wrote:
> At Fri, 27 Apr 2007 07:09:01 -0400,
> Jeff Mahoney wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Takashi Iwai wrote:
>>> At Fri, 27 Apr 2007 12:09:03 +0200,
>>> I wrote:
>>>> I got a similar bug right now at the fresh boot of 2.6.21.
>>>>
>>>>
>>>> ReiserFS: sda2: found reiserfs format "3.6" with standard journal
>>>> ReiserFS: sda2: using ordered data mode
>>>> ReiserFS: sda2: journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
>>>> ReiserFS: sda2: checking transaction log (sda2)
>>>> ReiserFS: sda2: Using r5 hash to sort names
>>>> ReiserFS: sda2: Removing [3613 1354701 0x0 SD]..done
>>>> ReiserFS: sda2: There were 1 uncompleted unlinks/truncates. Completed
>>>>
>>>> =======================================================
>>>> [ INFO: possible circular locking dependency detected ]
>>>> 2.6.21-work #1
>>>> -------------------------------------------------------
>>>> mktemp/1459 is trying to acquire lock:
>>>>  (&REISERFS_I(inode)->xattr_sem){..--}, at: [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>>>>
>>>> but task is already holding lock:
>>>>  (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2
>>>>
>>>> which lock already depends on the new lock.
>>> The message disappears when I revert the patch:
>>>
>>> commit 9b7f375505f5611efb562065b57814b28a81abc3
>>> Author: Jeff Mahoney <jeffm@suse.com>
>>> Date:   Mon Apr 23 14:41:17 2007 -0700
>>>
>>>     reiserfs: fix xattr root locking/refcount bug
>>>     
>>>
>>> So, likely a newly introduced bug after rc7...
>> I got a message with a trace similar to this from Vladimir before I
>> submitted that patch. I'm not sure how to annotate this, since the
>> xattr_sem can never be taken in the manner described. Internal inodes
>> are protected by I_PRIVATE.
> 
> Hm, then maybe my case was just a coincidence.
> 
> FWIW, I can reproduce the deadlock warning at each time I boot
> non-patched 2.6.21, and after reverting the patch, it disappeared.

Ok, so I took another look at the report Vladimir sent me. The trace he
ran into was in the delete inode path, but was still a race between the
xattr_sem and the inode sem. Since we're locking the xattr root on the
xattr read path now, this condition arises more freqently, but it's
really the same one he reported.

I'm using the default openSUSE config, which doesn't enable mutex
debugging. I'll rebuild with it, and hopefully come up with a way to
kill the warning.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGMhP8LPWxlyuTD7IRAiInAJwO7Tpga98WvcPICFMSyvb0vSAvrQCdEbal
XScT+lxIu181A6KNzKhNuYw=
=K/gK
-----END PGP SIGNATURE-----

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

* Re: 2.6.21 reiserfs -- cicular locking?
  2007-04-27 15:17           ` Jeff Mahoney
@ 2007-04-27 16:21             ` Jeff Mahoney
  2007-04-27 17:01               ` Takashi Iwai
  2007-04-27 17:11               ` Antonino A. Daplas
  0 siblings, 2 replies; 10+ messages in thread
From: Jeff Mahoney @ 2007-04-27 16:21 UTC (permalink / raw)
  To: Jeff Mahoney
  Cc: Takashi Iwai, Andrew Morton, David Brownell, Linux Kernel list,
	reiserfs-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Mahoney wrote:
> Takashi Iwai wrote:
>>> At Fri, 27 Apr 2007 07:09:01 -0400,
>>> Jeff Mahoney wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Takashi Iwai wrote:
>>>>> At Fri, 27 Apr 2007 12:09:03 +0200,
>>>>> I wrote:
>>>>>> I got a similar bug right now at the fresh boot of 2.6.21.
>>>>>>
>>>>>>
>>>>>> ReiserFS: sda2: found reiserfs format "3.6" with standard journal
>>>>>> ReiserFS: sda2: using ordered data mode
>>>>>> ReiserFS: sda2: journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
>>>>>> ReiserFS: sda2: checking transaction log (sda2)
>>>>>> ReiserFS: sda2: Using r5 hash to sort names
>>>>>> ReiserFS: sda2: Removing [3613 1354701 0x0 SD]..done
>>>>>> ReiserFS: sda2: There were 1 uncompleted unlinks/truncates. Completed
>>>>>>
>>>>>> =======================================================
>>>>>> [ INFO: possible circular locking dependency detected ]
>>>>>> 2.6.21-work #1
>>>>>> -------------------------------------------------------
>>>>>> mktemp/1459 is trying to acquire lock:
>>>>>>  (&REISERFS_I(inode)->xattr_sem){..--}, at: [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>>>>>>
>>>>>> but task is already holding lock:
>>>>>>  (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2
>>>>>>
>>>>>> which lock already depends on the new lock.
>>>>> The message disappears when I revert the patch:
>>>>>
>>>>> commit 9b7f375505f5611efb562065b57814b28a81abc3
>>>>> Author: Jeff Mahoney <jeffm@suse.com>
>>>>> Date:   Mon Apr 23 14:41:17 2007 -0700
>>>>>
>>>>>     reiserfs: fix xattr root locking/refcount bug
>>>>>     
>>>>>
>>>>> So, likely a newly introduced bug after rc7...
>>>> I got a message with a trace similar to this from Vladimir before I
>>>> submitted that patch. I'm not sure how to annotate this, since the
>>>> xattr_sem can never be taken in the manner described. Internal inodes
>>>> are protected by I_PRIVATE.
>>> Hm, then maybe my case was just a coincidence.
>>>
>>> FWIW, I can reproduce the deadlock warning at each time I boot
>>> non-patched 2.6.21, and after reverting the patch, it disappeared.
> 
> Ok, so I took another look at the report Vladimir sent me. The trace he
> ran into was in the delete inode path, but was still a race between the
> xattr_sem and the inode sem. Since we're locking the xattr root on the
> xattr read path now, this condition arises more freqently, but it's
> really the same one he reported.
> 
> I'm using the default openSUSE config, which doesn't enable mutex
> debugging. I'll rebuild with it, and hopefully come up with a way to
> kill the warning.

I still didn't get the warning, but can you try this and let me know
if it fixes it?

- -Jeff

- --- a/fs/reiserfs/xattr.c	2007-04-22 10:53:10.000000000 -0400
+++ b/fs/reiserfs/xattr.c	2007-04-27 12:09:02.000000000 -0400
@@ -68,7 +68,7 @@
 	if (!privroot)
 		return ERR_PTR(-ENODATA);
 
- -	mutex_lock(&privroot->d_inode->i_mutex);
+	mutex_lock_nested(&privroot->d_inode->i_mutex, I_MUTEX_XATTR);
 	if (REISERFS_SB(sb)->xattr_root) {
 		xaroot = dget(REISERFS_SB(sb)->xattr_root);
 		goto out;

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGMiL1LPWxlyuTD7IRAuwoAKCob0DLVBcmeOApOr9vA5cVFRwBewCfTU/U
jwIjK+Uy4RfXKsag5Uamzew=
=svba
-----END PGP SIGNATURE-----

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

* Re: 2.6.21 reiserfs -- cicular locking?
  2007-04-27 16:21             ` Jeff Mahoney
@ 2007-04-27 17:01               ` Takashi Iwai
  2007-04-27 17:11               ` Antonino A. Daplas
  1 sibling, 0 replies; 10+ messages in thread
From: Takashi Iwai @ 2007-04-27 17:01 UTC (permalink / raw)
  To: Jeff Mahoney
  Cc: Andrew Morton, David Brownell, Linux Kernel list, reiserfs-dev

At Fri, 27 Apr 2007 12:21:09 -0400,
Jeff Mahoney wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jeff Mahoney wrote:
> > Takashi Iwai wrote:
> >>> At Fri, 27 Apr 2007 07:09:01 -0400,
> >>> Jeff Mahoney wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Takashi Iwai wrote:
> >>>>> At Fri, 27 Apr 2007 12:09:03 +0200,
> >>>>> I wrote:
> >>>>>> I got a similar bug right now at the fresh boot of 2.6.21.
> >>>>>>
> >>>>>>
> >>>>>> ReiserFS: sda2: found reiserfs format "3.6" with standard journal
> >>>>>> ReiserFS: sda2: using ordered data mode
> >>>>>> ReiserFS: sda2: journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
> >>>>>> ReiserFS: sda2: checking transaction log (sda2)
> >>>>>> ReiserFS: sda2: Using r5 hash to sort names
> >>>>>> ReiserFS: sda2: Removing [3613 1354701 0x0 SD]..done
> >>>>>> ReiserFS: sda2: There were 1 uncompleted unlinks/truncates. Completed
> >>>>>>
> >>>>>> =======================================================
> >>>>>> [ INFO: possible circular locking dependency detected ]
> >>>>>> 2.6.21-work #1
> >>>>>> -------------------------------------------------------
> >>>>>> mktemp/1459 is trying to acquire lock:
> >>>>>>  (&REISERFS_I(inode)->xattr_sem){..--}, at: [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
> >>>>>>
> >>>>>> but task is already holding lock:
> >>>>>>  (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2
> >>>>>>
> >>>>>> which lock already depends on the new lock.
> >>>>> The message disappears when I revert the patch:
> >>>>>
> >>>>> commit 9b7f375505f5611efb562065b57814b28a81abc3
> >>>>> Author: Jeff Mahoney <jeffm@suse.com>
> >>>>> Date:   Mon Apr 23 14:41:17 2007 -0700
> >>>>>
> >>>>>     reiserfs: fix xattr root locking/refcount bug
> >>>>>     
> >>>>>
> >>>>> So, likely a newly introduced bug after rc7...
> >>>> I got a message with a trace similar to this from Vladimir before I
> >>>> submitted that patch. I'm not sure how to annotate this, since the
> >>>> xattr_sem can never be taken in the manner described. Internal inodes
> >>>> are protected by I_PRIVATE.
> >>> Hm, then maybe my case was just a coincidence.
> >>>
> >>> FWIW, I can reproduce the deadlock warning at each time I boot
> >>> non-patched 2.6.21, and after reverting the patch, it disappeared.
> > 
> > Ok, so I took another look at the report Vladimir sent me. The trace he
> > ran into was in the delete inode path, but was still a race between the
> > xattr_sem and the inode sem. Since we're locking the xattr root on the
> > xattr read path now, this condition arises more freqently, but it's
> > really the same one he reported.
> > 
> > I'm using the default openSUSE config, which doesn't enable mutex
> > debugging. I'll rebuild with it, and hopefully come up with a way to
> > kill the warning.
> 
> I still didn't get the warning, but can you try this and let me know
> if it fixes it?

Yes, it seems to fix the problem.


Thanks,

Takashi

> 
> - -Jeff
> 
> - --- a/fs/reiserfs/xattr.c	2007-04-22 10:53:10.000000000 -0400
> +++ b/fs/reiserfs/xattr.c	2007-04-27 12:09:02.000000000 -0400
> @@ -68,7 +68,7 @@
>  	if (!privroot)
>  		return ERR_PTR(-ENODATA);
>  
> - -	mutex_lock(&privroot->d_inode->i_mutex);
> +	mutex_lock_nested(&privroot->d_inode->i_mutex, I_MUTEX_XATTR);
>  	if (REISERFS_SB(sb)->xattr_root) {
>  		xaroot = dget(REISERFS_SB(sb)->xattr_root);
>  		goto out;
> 
> - -- 
> Jeff Mahoney
> SUSE Labs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
> 
> iD8DBQFGMiL1LPWxlyuTD7IRAuwoAKCob0DLVBcmeOApOr9vA5cVFRwBewCfTU/U
> jwIjK+Uy4RfXKsag5Uamzew=
> =svba
> -----END PGP SIGNATURE-----
> 

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

* Re: 2.6.21 reiserfs -- cicular locking?
  2007-04-27 16:21             ` Jeff Mahoney
  2007-04-27 17:01               ` Takashi Iwai
@ 2007-04-27 17:11               ` Antonino A. Daplas
  1 sibling, 0 replies; 10+ messages in thread
From: Antonino A. Daplas @ 2007-04-27 17:11 UTC (permalink / raw)
  To: Jeff Mahoney
  Cc: Jeff Mahoney, Takashi Iwai, Andrew Morton, David Brownell,
	Linux Kernel list, reiserfs-dev

On Fri, 2007-04-27 at 12:21 -0400, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jeff Mahoney wrote:
> > Takashi Iwai wrote:
> >>> At Fri, 27 Apr 2007 07:09:01 -0400,
> >>> Jeff Mahoney wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Takashi Iwai wrote:
> >>>>> At Fri, 27 Apr 2007 12:09:03 +0200,
> >>>>> I wrote:
> >>>>>> I got a similar bug right now at the fresh boot of 2.6.21.
> >>>>>>
> >>>>>>
> >>>>>> ReiserFS: sda2: found reiserfs format "3.6" with standard journal
> >>>>>> ReiserFS: sda2: using ordered data mode
> >>>>>> ReiserFS: sda2: journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
> >>>>>> ReiserFS: sda2: checking transaction log (sda2)
> >>>>>> ReiserFS: sda2: Using r5 hash to sort names
> >>>>>> ReiserFS: sda2: Removing [3613 1354701 0x0 SD]..done
> >>>>>> ReiserFS: sda2: There were 1 uncompleted unlinks/truncates. Completed
> >>>>>>
> >>>>>> =======================================================
> >>>>>> [ INFO: possible circular locking dependency detected ]
> >>>>>> 2.6.21-work #1
> >>>>>> -------------------------------------------------------
> >>>>>> mktemp/1459 is trying to acquire lock:
> >>>>>>  (&REISERFS_I(inode)->xattr_sem){..--}, at: [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
> >>>>>>
> >>>>>> but task is already holding lock:
> >>>>>>  (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2
> >>>>>>
> >>>>>> which lock already depends on the new lock.
> >>>>> The message disappears when I revert the patch:
> >>>>>
> >>>>> commit 9b7f375505f5611efb562065b57814b28a81abc3
> >>>>> Author: Jeff Mahoney <jeffm@suse.com>
> >>>>> Date:   Mon Apr 23 14:41:17 2007 -0700
> >>>>>
> >>>>>     reiserfs: fix xattr root locking/refcount bug
> >>>>>     
> >>>>>
> >>>>> So, likely a newly introduced bug after rc7...
> >>>> I got a message with a trace similar to this from Vladimir before I
> >>>> submitted that patch. I'm not sure how to annotate this, since the
> >>>> xattr_sem can never be taken in the manner described. Internal inodes
> >>>> are protected by I_PRIVATE.
> >>> Hm, then maybe my case was just a coincidence.
> >>>
> >>> FWIW, I can reproduce the deadlock warning at each time I boot
> >>> non-patched 2.6.21, and after reverting the patch, it disappeared.
> > 
> > Ok, so I took another look at the report Vladimir sent me. The trace he
> > ran into was in the delete inode path, but was still a race between the
> > xattr_sem and the inode sem. Since we're locking the xattr root on the
> > xattr read path now, this condition arises more freqently, but it's
> > really the same one he reported.
> > 
> > I'm using the default openSUSE config, which doesn't enable mutex
> > debugging. I'll rebuild with it, and hopefully come up with a way to
> > kill the warning.
> 
> I still didn't get the warning, but can you try this and let me know
> if it fixes it?

I also reported this in another thread.  With this patch, I haven't seen
the tracing anymore.

Tony



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

end of thread, other threads:[~2007-04-27 17:12 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-26 23:40 2.6.21 reiserfs -- cicular locking? David Brownell
2007-04-27  5:44 ` Andrew Morton
2007-04-27 10:09   ` Takashi Iwai
2007-04-27 10:53     ` Takashi Iwai
2007-04-27 11:09       ` Jeff Mahoney
2007-04-27 12:20         ` Takashi Iwai
2007-04-27 15:17           ` Jeff Mahoney
2007-04-27 16:21             ` Jeff Mahoney
2007-04-27 17:01               ` Takashi Iwai
2007-04-27 17:11               ` Antonino A. Daplas

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