Re: possible recursive locking in 2.6.30-rc6

[Dave Young <hidave.darkstar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

On Wed, May 27, 2009 at 3:42 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Dave,
>
>> Could you try the attached patch and report your result?
>
> please create patches with git-format-patch, because otherwise I have to
> do extra work to apply them.
>

Sorry about the inconvenience, actually I created the patch by quilt.

I just use git to monitor the latest kernel changes,  but do not use
it to create patches, I usually use a script of mine to create patch
manually.

Could you check the attached v2 patch? If it does not fit for
applying, I can start studying use git :)

> Regards
>
> Marcel
>
>
>



-- 
Regards
dave

[-- Attachment #2: bluetooth_flush_work_remove_v2.patch --]
[-- Type: application/octet-stream, Size: 2563 bytes --]

Lockdep warning reported by Oliver Hartkopp <oliver@hartkopp.net> 

=============================================
[ INFO: possible recursive locking detected ]
2.6.30-rc6-02911-gbb803cf #16
---------------------------------------------
bluetooth/2518 is trying to acquire lock:
 (bluetooth){+.+.+.}, at: [<c0130c14>] flush_work+0x28/0xb0

but task is already holding lock:
 (bluetooth){+.+.+.}, at: [<c0130424>] worker_thread+0x149/0x25e

other info that might help us debug this:
2 locks held by bluetooth/2518:
 #0:  (bluetooth){+.+.+.}, at: [<c0130424>] worker_thread+0x149/0x25e
 #1:  (&conn->work_del){+.+...}, at: [<c0130424>] worker_thread+0x149/0x25e

stack backtrace:
Pid: 2518, comm: bluetooth Not tainted 2.6.30-rc6-02911-gbb803cf #16
Call Trace:
 [<c03d64d9>] ? printk+0xf/0x11
 [<c0140d96>] __lock_acquire+0x7ce/0xb1b
 [<c0141173>] lock_acquire+0x90/0xad
 [<c0130c14>] ? flush_work+0x28/0xb0
 [<c0130c2e>] flush_work+0x42/0xb0
 [<c0130c14>] ? flush_work+0x28/0xb0
 [<f8b84966>] del_conn+0x1c/0x84 [bluetooth]
 [<c0130469>] worker_thread+0x18e/0x25e
 [<c0130424>] ? worker_thread+0x149/0x25e
 [<f8b8494a>] ? del_conn+0x0/0x84 [bluetooth]
 [<c0133843>] ? autoremove_wake_function+0x0/0x33
 [<c01302db>] ? worker_thread+0x0/0x25e
 [<c013355a>] kthread+0x45/0x6b
 [<c0133515>] ? kthread+0x0/0x6b
 [<c01034a7>] kernel_thread_helper+0x7/0x10

bluetoothd is a single thread workqueue, so work functions will execute in order.

Just remove the flush_work handling in hci_sysfs.c

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Reported-by: Oliver Hartkopp <oliver@hartkopp.net>
Tested-by: Oliver Hartkopp <oliver@hartkopp.net>
---
net/bluetooth/hci_sysfs.c |    6 ------
1 file changed, 6 deletions(-)

diff -urpN a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
--- a/net/bluetooth/hci_sysfs.c	2009-05-27 19:00:12.000000000 +0800
+++ b/net/bluetooth/hci_sysfs.c	2009-05-27 19:00:25.000000000 +0800
@@ -90,9 +90,6 @@ static void add_conn(struct work_struct 
 	struct hci_conn *conn = container_of(work, struct hci_conn, work_add);
 	struct hci_dev *hdev = conn->hdev;
 
-	/* ensure previous del is complete */
-	flush_work(&conn->work_del);
-
 	dev_set_name(&conn->dev, "%s:%d", hdev->name, conn->handle);
 
 	if (device_add(&conn->dev) < 0) {
@@ -118,9 +115,6 @@ static void del_conn(struct work_struct 
 	struct hci_conn *conn = container_of(work, struct hci_conn, work_del);
 	struct hci_dev *hdev = conn->hdev;
 
-	/* ensure previous add is complete */
-	flush_work(&conn->work_add);
-
 	if (!device_is_registered(&conn->dev))
 		return;