Re: [ckrm-tech] Circular Locking Dependency Chain detected in containers code

["Paul Menage" <menage@google.com>]

I'm away from work at the moment and can't investigate fully, but it
looks as though this may be the same one that I mentioned in the
introductory email to the patchset. If so, it's a false positive -
there's a point in the container mount code where we need to lock a
newly-created (and hence guaranteed unlocked) directory inode while
holding container mutex. This makes the lockdep code think that
inode->i_mutex nests inside container_mutex, when in fact
container_mutex nests outside inode->i_mutex in all cases except this
one case where i_mutex can't possibly be locked.

I've not learned enough about lockdep yet to figure out how to shut it
up in this case.

Thanks,

Paul

On 8/6/07, Dhaval Giani <dhaval@linux.vnet.ibm.com> wrote:
> Hi Paul,
>
> I have hit upon a circular locking dependency while doing an rmdir on a
> directory inside the containers code. I believe that it is safe as no one
> should be able to rmdir when a container is getting mounted.
>
> To reproduce it, just do a rmdir inside the container.
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.23-rc1-mm2-container #1
> -------------------------------------------------------
> rmdir/4321 is trying to acquire lock:
>  (container_mutex){--..}, at: [<c03f3fe0>] mutex_lock+0x21/0x24
>
> but task is already holding lock:
>  (&inode->i_mutex){--..}, at: [<c03f3fe0>] mutex_lock+0x21/0x24
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&inode->i_mutex){--..}:
>        [<c013bae1>] check_prev_add+0xae/0x18f
>        [<c013bc1c>] check_prevs_add+0x5a/0xc5
>        [<c013bee5>] validate_chain+0x25e/0x2cd
>        [<c013d892>] __lock_acquire+0x629/0x691
>        [<c013ddef>] lock_acquire+0x61/0x7e
>        [<c03f40b5>] __mutex_lock_slowpath+0xc8/0x230
>        [<c03f3fe0>] mutex_lock+0x21/0x24
>        [<c014749f>] container_get_sb+0x22c/0x283
>        [<c0174f02>] vfs_kern_mount+0x3a/0x73
>        [<c0186743>] do_new_mount+0x7e/0xdc
>        [<c0186d8b>] do_mount+0x178/0x191
>        [<c0186ff3>] sys_mount+0x66/0x9d
>        [<c0104cc2>] sysenter_past_esp+0x5f/0x99
>        [<ffffffff>] 0xffffffff
>
> -> #0 (container_mutex){--..}:
>        [<c013ba5e>] check_prev_add+0x2b/0x18f
>        [<c013bc1c>] check_prevs_add+0x5a/0xc5
>        [<c013bee5>] validate_chain+0x25e/0x2cd
>        [<c013d892>] __lock_acquire+0x629/0x691
>        [<c013ddef>] lock_acquire+0x61/0x7e
>        [<c03f40b5>] __mutex_lock_slowpath+0xc8/0x230
>        [<c03f3fe0>] mutex_lock+0x21/0x24
>        [<c01484f3>] container_rmdir+0x15/0x163
>        [<c017b711>] vfs_rmdir+0x59/0x8f
>        [<c017b7d3>] do_rmdir+0x8c/0xbe
>        [<c017b815>] sys_rmdir+0x10/0x12
>        [<c0104cc2>] sysenter_past_esp+0x5f/0x99
>        [<ffffffff>] 0xffffffff
>
> other info that might help us debug this:
>
> 2 locks held by rmdir/4321:
>  #0:  (&inode->i_mutex/1){--..}, at: [<c017b7b3>] do_rmdir+0x6c/0xbe
>  #1:  (&inode->i_mutex){--..}, at: [<c03f3fe0>] mutex_lock+0x21/0x24
>
> stack backtrace:
>  [<c0105ad0>] show_trace_log_lvl+0x12/0x22
>  [<c0105aed>] show_trace+0xd/0xf
>  [<c0105bc3>] dump_stack+0x14/0x16
>  [<c013b401>] print_circular_bug_tail+0x5b/0x64
>  [<c013ba5e>] check_prev_add+0x2b/0x18f
>  [<c013bc1c>] check_prevs_add+0x5a/0xc5
>  [<c013bee5>] validate_chain+0x25e/0x2cd
>  [<c013d892>] __lock_acquire+0x629/0x691
>  [<c013ddef>] lock_acquire+0x61/0x7e
>  [<c03f40b5>] __mutex_lock_slowpath+0xc8/0x230
>  [<c03f3fe0>] mutex_lock+0x21/0x24
>  [<c01484f3>] container_rmdir+0x15/0x163
>  [<c017b711>] vfs_rmdir+0x59/0x8f
>  [<c017b7d3>] do_rmdir+0x8c/0xbe
>  [<c017b815>] sys_rmdir+0x10/0x12
>  [<c0104cc2>] sysenter_past_esp+0x5f/0x99
>  =======================
> --
> regards,
> Dhaval
>
> I would like to change the world but they don't give me the source code!
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> ckrm-tech mailing list
> https://lists.sourceforge.net/lists/listinfo/ckrm-tech
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/