Empty critical section issue in Bluetooth Linux driver code

Empty critical section issue in Bluetooth Linux driver code

[@ 2010-07-13 10:50 UTC (permalink / raw)]

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 between
write_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,

-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Empty critical section issue in Bluetooth Linux driver code

[Dan Carpenter]

On Tue, Jul 13, 2010 at 12:50:40PM +0200, "Tegawendé F. Bissyandé" wrote:
> 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);
>

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

>     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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html