race condition in hci_usb.c?

Bluez-devel Jose Vasconcellos 2 participants 2 messages Sep 22, 2006 – Sep 25, 2006 Bluetooth drivers

Share & tools

Jose Vasconcellos

author

2006-09-22 18:08 UTC #0 lore raw

Hello,

I'm studying the hci_usb driver and I found a possible race condition. The routine hci_usb_tx_wakeup is called from hci_sub_send_frame and from hci_usb_tx_complete to get some work done by calling hci_usb_tx_process. It basically provides serial access to hci_usb_tx_process by using a couble of bit variables:
HCI_USB_TX_PROCESS and HCI_USB_TX_WAKEPUP.

The problem is that if hci_usb_tx_wakeup is invoked again from a different context while execution is just terminating hci_usb_tx_process (right after the while loop), then hci_usb_tx_process will miss the wakeup. This condition will correct itself when another call is made to hci_usb_send_frame or another urb finishes transmission.

I experimented by replacing hci_usb_tx_wakeup with a tasklet that schedules hci_usb_tx_process. This to me seems like a safer approach.

Regards,

Jose

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2006-09-25 21:40 UTC #1 lore raw

Hi Jose,

Quoted 13 lines

I'm studying the hci_usb driver and I found a possible race condition. The routine hci_usb_tx_wakeup is called from hci_sub_send_frame and from hci_usb_tx_complete to get some work done by calling hci_usb_tx_process. It basically provides serial access to hci_usb_tx_process by using a couble of bit variables:
HCI_USB_TX_PROCESS and HCI_USB_TX_WAKEPUP.
The problem is that if hci_usb_tx_wakeup is invoked again from a different context while execution is just terminating hci_usb_tx_process (right after the while loop), then hci_usb_tx_process will miss the wakeup. This condition will correct itself when another call is made to hci_usb_send_frame or another urb finishes transmission.

Quoted 3 lines

I experimented by replacing hci_usb_tx_wakeup with a tasklet that schedules hci_usb_tx_process. This to me seems like a safer approach.

feel free to provide a patch. In general the hci_usb driver needs a complete rewrite anyway.

Regards

Marcel