Bug 725669 - possible recursive locking detected in systemd-logind
possible recursive locking detected in systemd-logind
Status: CLOSED DUPLICATE of bug 722472
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-26 04:49 EDT by Daniel Mach
Modified: 2011-07-26 05:01 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-26 05:01:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Mach 2011-07-26 04:49:10 EDT
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 05:01:12 EDT

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

Note You need to log in before you can comment on or make changes to this bug.