Re: [TECH TOPIC] Rust for Linux

Greg KH
2021-07-07T12:20:29Z

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.

thanks,

greg k-h