Empty critical section issue in Bluetooth Linux driver code
Tegawendé F. Bissyandé
Hi,
I have been using Coccinelle to validate some trivial rules of kernel API use by device drivers.
I came accross the definition of an empty critical section in the 'bfusb_close' function in file drivers/bluetooth/bfusb.c
static int bfusb_close(struct hci_dev *hdev)
{
...
write_lock_irqsave(&data->lock, flags);
write_unlock_irqrestore(&data->lock, flags);
bfusb_unlink_urbs(data);
bfusb_flush(hdev);
return 0;
}This excerpt is from Linux 2.6.34, but the same code has been prevailing
long before (I've seen it in 2.6.5)
So I was wondering if there is some code that is supposed to go betweenwrite_lock_irqsave and write_unlock_irqsave,
or if the two statements should simply removed?
I also supposed that this was just meant to allow to wait for a release of the lock by another thread. In this case, wouldn't spin_lock or mutex_lock be more appropriate as write_lock can be confusing even though I suppose it has the same effect?? but I am not sure.
best regards,
Signature · 8 lines
Tegawendé F. Bissyandé PhD student at LaBRI - France -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · Tegawendé F. Bissyandé
Hi,
I have been using Coccinelle to validate some trivial rules of kernel API use by device drivers.
I came accross the definition of an empty critical section in the 'bfusb_close' function in filedrivers/bluetooth/bfusb.c
Quoted 6 lines
static int
bfusb_close(struct hci_dev *hdev){ ... write_lock_irqsave(&data->lock, flags); write_unlock_irqrestore(&data->lock, flags);
This is in the _close() function. It's waiting for all the readers to finish. Presumably it's already ensured that no new reader threads will launch.
regards,
dan carpenter
Quoted 5 lines
bfusb_unlink_urbs(data);
bfusb_flush(hdev);
return 0;
}--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html