Re: swallowed wakeup in hiddev

On Wed, 31 Jan 2007, Oliver Neukum wrote:

> in hiddev_ioctl() IO is submitted with usbhid_submit_report() and waited 
> for with usbhid_wait_io(), which uses the following condition:
> 	if (!wait_event_timeout(hid->wait, (!test_bit(HID_CTRL_RUNNING, &usbhid->iofl) &&
> 					!test_bit(HID_OUT_RUNNING, &usbhid->iofl)),
> 					10*HZ)) {
> It seems to me that in the case of concurrent IO this condition will swallow
> the wakeup and timeout. Or am I dense today?

Hi Oliver,

I don't currently see the scenario you are talking about, could you 
elaborate a little bit more, please?

Every URB submission (both ctrl and out) is paired with wake_up() in its 
completion handler. Before the wake_up() is issued, the HID_CTRL_RUNNING 
or HID_OUT_RUNNING flag is cleared. As this is a "1:1 pairing", it's 
guaranteed that there will once be a wake_up() called on the waitqueue 
with both the flags unset (if a timeout doesn't happen sooner, which is 
OK). If this "final" wake_up() is called before the usbhid_wait_io() is 
called, this is also OK, because then the condition will evaluate to true 
and the task won't event sleep on the waitqueue.

Thanks,

-- 
Jiri Kosina

-------------------------------------------------------------------------
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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel