Bug 863118 - [abrt]: [ INFO: possible recursive locking detected ]
[abrt]: [ INFO: possible recursive locking detected ]
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
18
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
abrt_hash:73f9a6514d892282fb2083ae957...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-04 09:18 EDT by Philip Easley
Modified: 2013-03-15 11:48 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-15 11:48:49 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 Philip Easley 2012-10-04 09:18:46 EDT
Additional info:
libreport version: 2.0.14
abrt_version:   2.0.13
cmdline:        BOOT_IMAGE=/vmlinuz-3.6.0-0.rc7.git1.4.fc18.x86_64 root=UUID=dece561a-f17d-4ad9-af45-40552960b7da ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 rhgb quiet LANG=en_US.UTF-8 KEYTABLE=us
kernel:         3.6.0-0.rc7.git1.4.fc18.x86_64

backtrace:
:[ INFO: possible recursive locking detected ]
:3.6.0-0.rc7.git1.4.fc18.x86_64 #1 Not tainted
:---------------------------------------------
:obex-data-serve/1471 is trying to acquire lock:
: (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at: [<ffffffffa02fa889>] bt_accept_dequeue+0xa9/0x190 [bluetooth]
:but task is already holding lock:
: (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at: [<ffffffffa04c857d>] rfcomm_sock_accept+0x5d/0x2d0 [rfcomm]
:other info that might help us debug this:
: Possible unsafe locking scenario:
:       CPU0
:       ----
:  lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
:  lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
: *** DEADLOCK ***
: May be due to missing lock nesting notation
:1 lock held by obex-data-serve/1471:
: #0:  (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at: [<ffffffffa04c857d>] rfcomm_sock_accept+0x5d/0x2d0 [rfcomm]
:stack backtrace:
:Pid: 1471, comm: obex-data-serve Not tainted 3.6.0-0.rc7.git1.4.fc18.x86_64 #1
:Call Trace:
: [<ffffffff810d593f>] __lock_acquire+0x15bf/0x1ae0
: [<ffffffff810d138b>] ? add_lock_to_list.isra.29.constprop.44+0x7b/0xd0
: [<ffffffff81021dc3>] ? native_sched_clock+0x13/0x80
: [<ffffffff81021e39>] ? sched_clock+0x9/0x10
: [<ffffffff810ac8c5>] ? sched_clock_cpu+0xc5/0x120
: [<ffffffff810d6541>] lock_acquire+0xa1/0x1f0
: [<ffffffffa02fa889>] ? bt_accept_dequeue+0xa9/0x190 [bluetooth]
: [<ffffffff81581acd>] lock_sock_nested+0x8d/0xa0
: [<ffffffffa02fa889>] ? bt_accept_dequeue+0xa9/0x190 [bluetooth]
: [<ffffffff810d70cd>] ? trace_hardirqs_on_caller+0x10d/0x1a0
: [<ffffffffa02fa889>] bt_accept_dequeue+0xa9/0x190 [bluetooth]
: [<ffffffffa04c8666>] rfcomm_sock_accept+0x146/0x2d0 [rfcomm]
: [<ffffffff810a98a0>] ? try_to_wake_up+0x350/0x350
: [<ffffffff8157f602>] sys_accept4+0xf2/0x200
: [<ffffffff816e7395>] ? sysret_check+0x22/0x5d
: [<ffffffff810d70cd>] ? trace_hardirqs_on_caller+0x10d/0x1a0
: [<ffffffff8110232c>] ? __audit_syscall_entry+0xcc/0x300
: [<ffffffff8157f720>] sys_accept+0x10/0x20
: [<ffffffff816e7369>] system_call_fastpath+0x16/0x1b
Comment 1 Josh Boyer 2012-11-12 16:01:24 EST
Are you still able to recreate this with kernel-debug-3.6.6 or newer?
Comment 2 Justin M. Forbes 2013-03-15 11:48:49 EDT
Closing insufficient data as needinfo has been set for some time with no response.

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