On Mon, Jul 4, 2011 at 9:40 PM, Greg KH <greg@xxxxxxxxx> wrote: > On Mon, Jul 04, 2011 at 06:13:49PM +0530, Amit Nagal wrote: >> Hi , >> >> if a application is doing read /write I/O with a usb device , in 2 >> different threads in userspace , > > What type of USB device? Thanx for reply . i am using USB hid interface and using USBHID driver with hid-raw device interface . Actually i have 2 threads in userspace app : one for read and another one for write . my problem is like this : In case of usb disconnect , if read() returns first with error and application calls close() in read thread itself in userspace , while write() is still in progress() in usb driver in a separate thread , is this ok and safe ? or shall the application be designed such that both until read and write return with error , it should not call close in userspace ? Also to test this , i applied a 10 seconds delay at the end of hidraw_read() function in hidraw driver like : static ssize_t hidraw_read(struct file *file, char __user *buffer, size_t count, loff_t *ppos) { ............................................ /********************* test block starts */ printk(KERN_EMERG "[%s] - sleep start\n" , __func__); mdelay(10000); /* 10s delay */ printk(KERN_EMERG "[%s] - sleep end\n" , __func__); /***************** test block ends */ mutex_unlock(&list->read_mutex); return ret; } now while hidraw_read is executing 10s delay , i disconnects usb device , calls close(fd) . i observed , while close(fd) returns with 0 successfully immediately , usb driver release() function corresponding to close() was called only when hidraw_read returns after completing delay which is approx 9s later calling to close() in userspace . so do the usb-core layers or VFS layers maintains some locks that take care that if read / write is in progress and application calls close() , corresponding release() method in usb driver will be called only upon completion of all read / writes ? Regards Amit Nagal -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html