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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6599ad830708071310i4fa7a98age169e2d650421d8b@mail.gmail.com>
Date:	Tue, 7 Aug 2007 13:10:58 -0700
From:	"Paul Menage" <menage@...gle.com>
To:	"Dhaval Giani" <dhaval@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.com,
	"Srivatsa Vaddagiri" <vatsa@...ux.vnet.ibm.com>,
	ckrm-tech@...ts.sourceforge.net
Subject: Re: [ckrm-tech] Circular Locking Dependency Chain detected in containers code

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@...ux.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/