Bug 725669

Summary: possible recursive locking detected in systemd-logind
Product: [Fedora] Fedora Reporter: Daniel Mach <dmach>
Component: systemdAssignee: Lennart Poettering <lpoetter>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: harald, johannbg, lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-26 09:01:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Daniel Mach 2011-07-26 08:49:10 UTC
Version: systemd-30-1.fc16.i686

This is what I get during boot:

[  120.029096] =============================================
[  120.030018] [ INFO: possible recursive locking detected ]
[  120.030018] 3.0.0-1.fc16.i686 #1
[  120.030018] ---------------------------------------------
[  120.030018] systemd-logind/834 is trying to acquire lock:
[  120.030018]  (&ep->mtx){+.+.+.}, at: [<c052a355>] ep_scan_ready_list+0x32/0x154
[  120.030018] 
[  120.030018] but task is already holding lock:
[  120.030018]  (&ep->mtx){+.+.+.}, at: [<c052a7f4>] sys_epoll_ctl+0x103/0x481
[  120.030018] 
[  120.030018] other info that might help us debug this:
[  120.030018]  Possible unsafe locking scenario:
[  120.030018] 
[  120.030018]        CPU0
[  120.030018]        ----
[  120.030018]   lock(&ep->mtx);
[  120.041434]   lock(&ep->mtx);
[  120.041434] 
[  120.041434]  *** DEADLOCK ***
[  120.041434] 
[  120.041434]  May be due to missing lock nesting notation
[  120.041434] 
[  120.041434] 2 locks held by systemd-logind/834:
[  120.041434]  #0:  (epmutex){+.+.+.}, at: [<c052a7af>] sys_epoll_ctl+0xbe/0x481
[  120.041434]  #1:  (&ep->mtx){+.+.+.}, at: [<c052a7f4>] sys_epoll_ctl+0x103/0x481
[  120.041434] 
[  120.041434] stack backtrace:
[  120.041434] Pid: 834, comm: systemd-logind Not tainted 3.0.0-1.fc16.i686 #1
[  120.041434] Call Trace:
[  120.041434] Call Trace:
[  120.041434]  [<c083331f>] ? printk+0x2d/0x2f
[  120.041434]  [<c046b92f>] __lock_acquire+0x805/0xb57
[  120.041434]  [<c0407cc3>] ? sched_clock+0x8/0xb
[  120.060566]  [<c045d7dc>] ? sched_clock_local+0x10/0x18b
[  120.060566]  [<c052a355>] ? ep_scan_ready_list+0x32/0x154
[  120.060566]  [<c046c095>] lock_acquire+0xad/0xe4
[  120.060566]  [<c052a355>] ? ep_scan_ready_list+0x32/0x154
[  120.060566]  [<c083a7f5>] __mutex_lock_common+0x49/0x2ee
[  120.060566]  [<c052a355>] ? ep_scan_ready_list+0x32/0x154
[  120.060566]  [<c046c318>] ? mark_held_locks+0x3b/0x57
[  120.060566]  [<c0433414>] ? __might_sleep+0x29/0xfb
[  120.060566]  [<c046af5e>] ? mark_lock+0x26/0x1f2
[  120.060566]  [<c083abb4>] mutex_lock_nested+0x43/0x49
[  120.060566]  [<c052a355>] ? ep_scan_ready_list+0x32/0x154
[  120.060566]  [<c052a355>] ep_scan_ready_list+0x32/0x154
[  120.060566]  [<c0529f2f>] ? ep_remove+0x9b/0x9b
[  120.060566]  [<c052a48b>] ep_poll_readyevents_proc+0x14/0x16
[  120.060566]  [<c052a13a>] ep_call_nested.constprop.2+0x6d/0x9a
[  120.060566]  [<c052a477>] ? ep_scan_ready_list+0x154/0x154
[  120.060566]  [<c052a236>] ep_eventpoll_poll+0x45/0x55
[  120.060566]  [<c052a8f0>] sys_epoll_ctl+0x1ff/0x481
[  120.060566]  [<c052a05f>] ? ep_send_events_proc+0xd5/0xd5
[  120.092049]  [<c083c2e4>] syscall_call+0x7/0xb


The issue is 100% reproducible.
If you need more info, please let me know.

Comment 1 Michal Schmidt 2011-07-26 09:01:12 UTC

*** This bug has been marked as a duplicate of bug 722472 ***