Re: [TECH TOPIC] Rust for Linux

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2021-07-07 at 14:20 +0200, Greg KH wrote:
> On Wed, Jul 07, 2021 at 12:34:31PM +0100, James Bottomley wrote:
> > On Wed, 2021-07-07 at 11:50 +0100, Mark Brown wrote:
> > > On Tue, Jul 06, 2021 at 10:36:14PM +0200, Linus Walleij wrote:
> > > > On Tue, Jul 6, 2021 at 10:00 PM Roland Dreier <
> > > > roland@kernel.org>
> > > > wrote:
> > > > > "devres" / devm_xxx was an attempt to deal with this in C,
> > > > > but it only solves some cases of this and has not received a
> > > > > lot of adoption (we can argue about the reasons).
> > > >  
> > > > Really? From my point of view that is adopted all over the map.
> > > > I add new users all the time and use it as much as I can when
> > > > writing new drivers.
> > > 
> > > Yes, it's *super* widely used in most of the kernel.  Perhaps
> > > there's some subsystems that reject it for some reason.
> > > 
> > > > I think it's a formidable success, people just need to learn to
> > > > do it more.
> > > 
> > > There *are* issues with people adopting it too enthusiastically -
> > > as well as the memory lifetime issues that Laurent mentioned it's
> > > easy for it to cause problems with interrupt handlers that are
> > > left live longer than they should be and try to use things that
> > > were already deallocated.
> > 
> > Fixing this should not be beyond the wit of humankind, though.  If
> > we delayed deallocation to module release, that would fix the
> > interrupt issue, wouldn't it?  Perhaps all devres memory for
> > devices should live until then anyway and thus be automatically
> > deallocated instead of needing an explicit free ... the problem
> > with that being compiled in devices currently optimize away the
> > module refcounting, but that should be fixable.
> 
> module code lifespans are different than device structure lifespans,
> it's when people get them confused, as here, that we have problems.

I'm not claiming they are.  What I am claiming is that module lifetime
must always encompass the device lifetimes.  Therefore, you can never
be incorrect by using a module lifetime for anything attached to a
device, just inefficient for using memory longer than potentially
needed.  However, in a lot of use cases, the device is created on
module init and destroyed on module exit, so the inefficiency is barely
noticeable.  The question I'm asking is shouldn't we optimize for this?
so let people allocate devm memory safe in the knowledge it will be
freed on module release?  It will certainly fix a lot of the use after
free reports and we can still keep devm_release around for cases where
devices really do appear and disappear multiple times over the life of
the module.

James