This came in this morning from a user of a slightly old kernel now, but

I don't see anything obvious post rc5 that would fix this.
	Dave
Mar 27 08:10:57 localhost kernel: =============================================

Mar 27 08:10:57 localhost kernel: [ INFO: possible recursive locking detected ]

Mar 27 08:10:57 localhost kernel: 2.6.25-0.121.rc5.git4.fc9 #1

Mar 27 08:10:57 localhost kernel: ---------------------------------------------

Mar 27 08:10:57 localhost kernel: obex-data-serve/3611 is trying to acquire lock:

Mar 27 08:10:57 localhost kernel:  (sk_lock-AF_BLUETOOTH){--..}, at: [<f8bd9321>] l2cap_sock_bind+0x29/0x108 [l2cap]

Mar 27 08:10:57 localhost kernel:

Mar 27 08:10:57 localhost kernel: but task is already holding lock:

Mar 27 08:10:57 localhost kernel:  (sk_lock-AF_BLUETOOTH){--..}, at: [<f8dae136>] rfcomm_sock_connect+0x35/0xc2 [rfcomm]

Mar 27 08:10:57 localhost kernel:

Mar 27 08:10:57 localhost kernel: other info that might help us debug this:

Mar 27 08:10:57 localhost kernel: 2 locks held by obex-data-serve/3611:

Mar 27 08:10:57 localhost kernel:  #0:  (sk_lock-AF_BLUETOOTH){--..}, at: [<f8dae136>] rfcomm_sock_connect+0x35/0xc2 [rfcomm]

Mar 27 08:10:57 localhost kernel:  #1:  (rfcomm_mutex){--..}, at: [<f8dad337>] rfcomm_dlc_open+0x28/0x294 [rfcomm]

Mar 27 08:10:57 localhost kernel:

Mar 27 08:10:57 localhost kernel: stack backtrace:

Mar 27 08:10:57 localhost kernel: Pid: 3611, comm: obex-data-serve Not tainted 2.6.25-0.121.rc5.git4.fc9 #1

Mar 27 08:10:57 localhost kernel:  [__lock_acquire+2287/3089] __lock_acquire+0x8ef/0xc11

Mar 27 08:10:57 localhost kernel:  [sched_clock+8/11] ? sched_clock+0x8/0xb

Mar 27 08:10:57 localhost kernel:  [lock_acquire+106/144] lock_acquire+0x6a/0x90

Mar 27 08:10:57 localhost kernel:  [<f8bd9321>] ? l2cap_sock_bind+0x29/0x108 [l2cap]

Mar 27 08:10:57 localhost kernel:  [lock_sock_nested+182/198] lock_sock_nested+0xb6/0xc6

Mar 27 08:10:57 localhost kernel:  [<f8bd9321>] ? l2cap_sock_bind+0x29/0x108 [l2ca...
[ message continues ]

From: Dave Jones <davej@codemonkey.org.uk>
rfcomm connect locks the socket, then does rfcomm_dlc_open which in

turn can do a l2cap_sock_bind on a seperate second socket which in

turn locks that second socket.
Both of these sockets are AF_BLUETOOTH family, so lockdep thinks there

is a locking conflict, even though what is happening here is perfectly

fine since the two sockets are totally different AF_BLUETOOTH

sub-types.
Bluetooth will need to use sock_lock_init_class_and_name() and

lock sub-classes per AF_BLUETOOTH socket sub-type.
David, could you or someone else work on this?
Thanks!
--

Hi, I known this problem and did some work on this, but not finished

due to lacking time.
I will continue working on it when I'm free.
Regards

--

From: "Dave Young" <hidave.darkstar@gmail.com>
Thank you.

--