Bug 863118 - [abrt]: [ INFO: possible recursive locking detected ]
Summary: [abrt]: [ INFO: possible recursive locking detected ]
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:73f9a6514d892282fb2083ae957...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-04 13:18 UTC by Philip Easley
Modified: 2013-03-15 15:48 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-15 15:48:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Philip Easley 2012-10-04 13:18:46 UTC
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 21:01:24 UTC
Are you still able to recreate this with kernel-debug-3.6.6 or newer?

Comment 2 Justin M. Forbes 2013-03-15 15:48:49 UTC
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.