Re: [PATCH 6/8] rust: add revocable mutex

[Danilo Krummrich <dakr@redhat.com>]

On Tue, Mar 26, 2024 at 07:17:59PM +0100, Greg KH wrote:
> On Tue, Mar 26, 2024 at 07:13:13PM +0100, Danilo Krummrich wrote:
> > On Mon, Mar 25, 2024 at 07:22:15PM +0100, Greg KH wrote:
> > > On Mon, Mar 25, 2024 at 06:49:10PM +0100, Danilo Krummrich wrote:
> > > > From: Wedson Almeida Filho <wedsonaf@gmail.com>
> > > > 
> > > > This is a mutex where access to its contents can be revoked at runtime.
> > > > 
> > > > This is different from `Revocable` in a few ways:
> > > >   1. The caller may sleep while holding a guard.
> > > >   2. Accessors are all serialised.
> > > >   3. Accessing is not as cheap (because it involves acquiring the mutex).
> > > >   4. The size of the object is larger (because it involves a mutex +
> > > >      flag).
> > > > 
> > > > An example of where this a good fit to be used in device state that
> > > > holds registrations to other subsystems.
> > > 
> > > Why don't we need this in .c files if it is so needed in drivers today?
> > 
> > You mean revoking access to a resource in general? 
> 
> I mean "having a mutex that can be revokable" as you describe here.  Why
> is a driver written in rust unique in needing this?

Let's go back to the idea of a Revocable<>. As already mentioned the idea is to
make sure a driver can not access a ressource after it has been gone, e.g. a
pointer to an MMIO mapping after it has been unmapped (e.g. by devres). To
synchronize access, Revocable<> uses RCU; we need to wait to revoke the resource
until a potential access by the driver has been finished.

RevocableMutex does the same thing, but uses a Mutex instead of RCU, which leads
to the differences listed above.

As for "why does only Rust need this", I don't think it does. Conceptually,
there are quite similar approaches on the C side. As already mentioned DRM uses
drm_dev_unplug() and drm_dev_{enter,exit}(). There may be other subsystem
specific C implementations that do something similar I don't know about.

I think one difference might be that in C we can sometimes get away with just
knowing that something can't happen and hence isn't protected, whereas in Rust
we want / have to give the safety guarantee no matter what.

> 
> thanks,
> 
> greg k-h
>