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. 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. Alan Stern
