On Sat, 6 Mar 2010, Dmitry Torokhov wrote: > > > > 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 the alternative is insane locking and the resulting bugs from that, then it _is_ "realistically needed". That said, other approaches that doesn't need the locking at all are obviously preferable: > 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. I would also suggest that maybe conndiscevcnt (what a particularly crappy name, btw) shouldn't need a lock at all. Make it atomic, and make the rules be: - on the writer side, increment it _before_ doing the wakeup (we already do). The wakeup will imply a wmb() too. - on the reader side, re-check the counter and the event state we're waiting for _after_ adding us to the wait queue (adding outselves to the wait queues will have implied an rmb()) and now there's no need to take a lock just to access conndiscevcnt, afaik. Linus -- 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
