Hi Alan On Thu, 20 Oct 2022 at 00:08, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Oct 19, 2022 at 01:22:48PM +0900, Ricardo Ribalda wrote: > > Hi Laurent > > > > On Wed, 19 Oct 2022 at 10:45, Laurent Pinchart > > <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > > And I would like to avoid having to roll out manual changes to all > > > drivers when the problem can be fixed in the core, just because nobody > > > can be bothered to spend time to implement a good fix. We don't have to > > > aim for a solution at the cdev level if that takes too long, an > > > implementation in V4L2 would be enough to start with. > > > > Do we know what a "good fix" would look like?. This is a race > > condition between cdev, v4l2, and usb_driver. The only entity that > > knows about the three of them is the driver. > > > > If we "fix" v4l2 to provide a callback to notify the framework about a > > "bus disconnect". It can prevent new syscalls, but it cannot interrupt > > the current ones. > > It doesn't need to interrupt current syscalls. It merely needs to wait > until the current ones complete (and help them to complete early by > making them aware of the disconnection) and to prevent new ones from > starting. > The USB subsystem is not aware of the current syscalls running for that device, it just triggers the callback disconnect() to notify the driver that they are not allowed anymore to access the hardware. Even when/if we fix this for real, a "basic test" checking if the device is disconnected is a nice thing to have. I think of it as a protective programming :) Something like: if WARN_ON(is_connected) return -EIO; > I have no idea what facility (if any) the framework uses for this > already. However, if it turns out that proper synchronization needs a > new approach, I suggest trying SRCU. It can be viewed in some respects > as a kind of read-write mutex that is highly optimized for rapid > read-locks and -unlocks at the cost of very slow write-locks -- > appropriate here since every syscall would need a read-lock whereas > write-locking would be needed only when a disconnect occurs. Thanks for the pointer :) > > Alan Stern -- Ricardo Ribalda
