On Sat, Mar 06, 2010 at 11:27:01AM -0500, Alan Stern wrote: > On Sat, 6 Mar 2010, Oliver Neukum wrote: > > > Am Samstag, 6. März 2010 16:34:31 schrieb Alan Stern: > > > On Sat, 6 Mar 2010, Oliver Neukum wrote: > > > > > > The caller of usbfs_conn_disc_event() already holds usbfs_mutex. > > > > Don't take it again. > > > > > > That's not true. The caller holds usbfs_mutex only when the action is > > > USB_DEVICE_REMOVE. Not when the action is USB_DEVICE_ADD or USB_BUS_*. > > > > Right. That's what you get for wanting a quick fix. What do you > > propose? > > Guard conndiscevcnt and file->private_data with a separate static > mutex instead of usbfs_mutex. > If you think it is important use atomic here, however I do not think it is realistically needed. If we have 2 devices appearing and disappearing at the same time we may "skip" version but still anyone issuing select() before that will get woken up and will see both in /proc. > Incidentally, what's supposed to happen if more than one thread tries > to poll the same file descriptor simultaneously? Do you really want > the first thread to wait only until the first event while the second > thread is forced to wait for a second event? I think it is like with read and write - if userspace does not do proper locking while accessing the same fd it gets to hold both pieces. So again, no reason for using mutex there either. Also, if you use file->f_version you would not need kallocing that single integer and then having to free it. See how it is done in input. Thanks. -- Dmitry -- 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
