Samuel Ortiz wrote:
> Oliver Neukum wrote:
>> Am Donnerstag, 15. Februar 2007 19:35 schrieb Greg KH:
>>> On Thu, Feb 15, 2007 at 01:51:31PM +0100, Oliver Neukum wrote:
>>>> Am Donnerstag, 15. Februar 2007 00:31 schrieb [EMAIL PROTECTED]:
>>>>> +??????????????dev = (struct iowarrior *)file->private_data;
>>>>> +
>>>>> +??????????????/* verify that the device wasn't unplugged */
>>>>> +??????????????if (dev == NULL || !dev->present) {
>>>>> +??????????????????????????????retval = -ENODEV;
>>>>> +??????????????????????????????goto exit;
>>>>> +??????????????}
>>>> This needs the lock to be taken. You've a race condition that allows
>>>> URBs to be submitted for an interface that somebody else may have
>>>> claimed.
>>> Which lock?  The disconnect_sem one?
>> mutex_lock(&dev->mutex);
>> The same that is already taken in the ioctl handler.
> One stupid question: Suppose we're in iowarrior_read(), got a pointer on 
> private_data, but haven't taken the mutex yet. iowarrior_release() is 
> called, locks the mutex, decrements the opened counter to 0, and then 
> call iowarrior_delete(). iowarrior_read() resumes, and tries to grab 
> dev->mutex, but at that point dev is NULL, and we oops. How is that case 
> handled ?
Ok, I guess the VFS code somehow handles that and makes sure that 
close() is deffered while some I/O is running on the device. Does that 
make sense ?

Cheers,
Samuel.

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

Reply via email to