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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw@mail.gmail.com>
Date:	Tue, 8 Nov 2011 05:47:55 +0200
From:	Ari Savolainen <ari.m.savolainen@...il.com>
To:	Vasiliy Kulikov <segoon@...nwall.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: lockdep warning after aa6afca5bcab: "proc: fix races against execve()
 of /proc/PID/fd**"

The following lockep warning is caused by commit aa6afca5bcab: "proc:
fix races against execve() of /proc/PID/fd**":

[    3.961193] ======================================================
[    3.961200] [ INFO: possible circular locking dependency detected ]
[    3.961208] 3.2.0-rc1 #1
[    3.961212] -------------------------------------------------------
[    3.961219] udevd/709 is trying to acquire lock:
[    3.961225]  (&sig->cred_guard_mutex){+.+.+.}, at:
[<ffffffff811c4ccd>] lock_trace+0x2d/0x70
[    3.961244]
[    3.961244] but task is already holding lock:
[    3.961251]  (&sb->s_type->i_mutex_key#5){+.+.+.}, at:
[<ffffffff81172a08>] do_lookup+0x2a8/0x3d0
[    3.961268]
[    3.961269] which lock already depends on the new lock.
[    3.961270]
[    3.961279]
[    3.961279] the existing dependency chain (in reverse order) is:
[    3.961288]
[    3.961288] -> #1 (&sb->s_type->i_mutex_key#5){+.+.+.}:
[    3.961300]        [<ffffffff81090250>] lock_acquire+0x90/0x1f0
[    3.961310]        [<ffffffff814bde70>] mutex_lock_nested+0x50/0x3b0
[    3.961321]        [<ffffffff81172a08>] do_lookup+0x2a8/0x3d0
[    3.961329]        [<ffffffff81173381>] link_path_walk+0x151/0x8a0
[    3.961338]        [<ffffffff81175378>] path_openat+0xb8/0x3a0
[    3.961346]        [<ffffffff81175782>] do_filp_open+0x42/0xa0
[    3.961354]        [<ffffffff8116bce2>] open_exec+0x32/0xf0
[    3.961363]        [<ffffffff8116cd97>] do_execve_common.isra.34+0x137/0x340
[    3.961373]        [<ffffffff8116cfbb>] do_execve+0x1b/0x20
[    3.961381]        [<ffffffff8100bfe7>] sys_execve+0x47/0x70
[    3.961391]        [<ffffffff814c7f8c>] stub_execve+0x6c/0xc0
[    3.961401]
[    3.961401] -> #0 (&sig->cred_guard_mutex){+.+.+.}:
[    3.961412]        [<ffffffff8108f7b8>] __lock_acquire+0x16f8/0x1b10
[    3.961421]        [<ffffffff81090250>] lock_acquire+0x90/0x1f0
[    3.961429]        [<ffffffff814be68f>] mutex_lock_killable_nested+0x5f/0x470
[    3.961438]        [<ffffffff811c4ccd>] lock_trace+0x2d/0x70
[    3.961447]        [<ffffffff811c6806>] proc_lookupfd_common+0x66/0xd0
[    3.961457]        [<ffffffff811c68a5>] proc_lookupfd+0x15/0x20
[    3.961465]        [<ffffffff81170425>] d_alloc_and_lookup+0x45/0x90
[    3.961474]        [<ffffffff81172a32>] do_lookup+0x2d2/0x3d0
[    3.961483]        [<ffffffff81173cf4>] path_lookupat+0x134/0x740
[    3.961492]        [<ffffffff81174331>] do_path_lookup+0x31/0xc0
[    3.961500]        [<ffffffff811756d9>] user_path_at_empty+0x59/0xa0
[    3.961509]        [<ffffffff81175731>] user_path_at+0x11/0x20
[    3.961517]        [<ffffffff81169fca>] vfs_fstatat+0x3a/0x70
[    3.961526]        [<ffffffff8116a03b>] vfs_stat+0x1b/0x20
[    3.961533]        [<ffffffff8116a17a>] sys_newstat+0x1a/0x40
[    3.961542]        [<ffffffff814c7aeb>] system_call_fastpath+0x16/0x1b
[    3.961552]
[    3.961552] other info that might help us debug this:
[    3.961553]
[    3.961562]  Possible unsafe locking scenario:
[    3.961563]
[    3.961569]        CPU0                    CPU1
[    3.961574]        ----                    ----
[    3.961580]   lock(&sb->s_type->i_mutex_key);
[    3.961587]                                lock(&sig->cred_guard_mutex);
[    3.961596]                                lock(&sb->s_type->i_mutex_key);
[    3.961605]   lock(&sig->cred_guard_mutex);
[    3.961612]
[    3.961612]  *** DEADLOCK ***
[    3.961613]
[    3.961621] 1 lock held by udevd/709:
[    3.961626]  #0:  (&sb->s_type->i_mutex_key#5){+.+.+.}, at:
[<ffffffff81172a08>] do_lookup+0x2a8/0x3d0
[    3.961642]
[    3.961643] stack backtrace:
[    3.961650] Pid: 709, comm: udevd Not tainted 3.2.0-rc1 #1
[    3.961656] Call Trace:
[    3.961664]  [<ffffffff814b5aed>] print_circular_bug+0x23d/0x24e
[    3.961673]  [<ffffffff8108f7b8>] __lock_acquire+0x16f8/0x1b10
[    3.961681]  [<ffffffff8108e473>] ? __lock_acquire+0x3b3/0x1b10
[    3.961690]  [<ffffffff81090250>] lock_acquire+0x90/0x1f0
[    3.961698]  [<ffffffff811c4ccd>] ? lock_trace+0x2d/0x70
[    3.961706]  [<ffffffff814be68f>] mutex_lock_killable_nested+0x5f/0x470
[    3.961715]  [<ffffffff811c4ccd>] ? lock_trace+0x2d/0x70
[    3.961723]  [<ffffffff810731c0>] ? pid_task+0xa0/0xa0
[    3.961731]  [<ffffffff811c4ccd>] ? lock_trace+0x2d/0x70
[    3.961739]  [<ffffffff811c8470>] ? proc_fdinfo_instantiate+0xa0/0xa0
[    3.961748]  [<ffffffff811c4ccd>] lock_trace+0x2d/0x70
[    3.961755]  [<ffffffff811c6806>] proc_lookupfd_common+0x66/0xd0
[    3.961764]  [<ffffffff811c68a5>] proc_lookupfd+0x15/0x20
[    3.961772]  [<ffffffff81170425>] d_alloc_and_lookup+0x45/0x90
[    3.961781]  [<ffffffff8117ea35>] ? d_lookup+0x35/0x60
[    3.961789]  [<ffffffff81172a32>] do_lookup+0x2d2/0x3d0
[    3.961797]  [<ffffffff81173cf4>] path_lookupat+0x134/0x740
[    3.961806]  [<ffffffff81130479>] ? might_fault+0x89/0x90
[    3.961815]  [<ffffffff8115ae18>] ? kmem_cache_alloc+0x38/0x210
[    3.961825]  [<ffffffff81281557>] ? __strncpy_from_user+0x27/0x60
[    3.961833]  [<ffffffff81174331>] do_path_lookup+0x31/0xc0
[    3.961840]  [<ffffffff811756d9>] user_path_at_empty+0x59/0xa0
[    3.961850]  [<ffffffff81184270>] ? vfsmount_lock_local_lock_cpu+0x80/0x80
[    3.961858]  [<ffffffff8117d5de>] ? dput+0x2e/0x260
[    3.961865]  [<ffffffff81175731>] user_path_at+0x11/0x20
[    3.961873]  [<ffffffff81169fca>] vfs_fstatat+0x3a/0x70
[    3.961880]  [<ffffffff811708e3>] ? putname+0x33/0x50
[    3.961888]  [<ffffffff81090d55>] ? trace_hardirqs_on_caller+0x105/0x190
[    3.961897]  [<ffffffff8116a03b>] vfs_stat+0x1b/0x20
[    3.961904]  [<ffffffff8116a17a>] sys_newstat+0x1a/0x40
[    3.961911]  [<ffffffff81090d55>] ? trace_hardirqs_on_caller+0x105/0x190
[    3.961920]  [<ffffffff8128114e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[    3.961929]  [<ffffffff814c7aeb>] system_call_fastpath+0x16/0x1b
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ