On Sun, Jan 25, 2026 at 01:47:14PM +0100, Greg KH wrote: > On Sat, Jan 24, 2026 at 08:08:28PM +0100, Danilo Krummrich wrote: > > On Sat Jan 24, 2026 at 6:05 PM CET, Johan Hovold wrote: > > > this does not look like the right interface for the chardev unplug issue. > > > > I think it depends, we should do everything to prevent having the issue in > > the > > first place, e.g. ensure that we synchronize the unplug properly on device > > driver unbind. > > > > Sometimes, however, this isn't possible; this is where a revocable > > mechanism can > > come in handy to prevent UAF of device resources -- DRM is a good example > > for > > this. > > This is not "possible" for almost all real devices so we need something > like this for almost all classes of devices, DRM just shows the extremes > involved, v4l2 is also another good example.
Revocable is not needed in V4L2. > Note, other OSes also have this same problem, look at all the work the > BSDs are going through at the moment just to get closer to the place > where we are in Linux today with removable devices and they have hit our > same problems. > > > But to be fair, I also want to point out that there is a quite significant > > difference regarding the usefulness of the revocable concept in C compared > > to in > > Rust due to language capabilities. > > True, but we do need something. I took these patches without a real > user as a base for us to start working off of. The rust implementation > has shown that the design-pattern is a good solution for the problem, > and so I feel we should work with it and try to get this working > properly. We've been sitting and talking about it for years now, and > here is the first real code submission that is getting us closer to fix > the problem properly. It might not be perfict, but let's evolve it from > here for what is found not to work correctly. > > So I don't want to take these reverts, let's try this out, by putting > this into the driver core now, we have the base to experiment with in a > "safe" way in lots of different driver subsytems at the same time. If > it doesn't work out, worst case we revert it in a release or two because > it didn't get used. -- Regards, Laurent Pinchart
