Re: [TECH TOPIC] Rust for Linux

James Bottomley
2021-07-07T11:27:43Z

On Wed, 2021-07-07 at 12:56 +0200, Julia Lawall wrote:
>
> On Wed, 7 Jul 2021, 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.
>
> I was also wondering what would be done with Rust in the case of this
> issue.

Pretty much nothing. Rust has a tracking system for exclusive memory
allocations, which is where it gets its memory safety guarantees.
However, once you move the reference counting the guarantees become
much weaker. The best it can do for us is the same as the current
kasan: detect use after free at runtime but not at compile time.

To have compile time tracking of reference counts, we'd have to encode
the lifetime rules semantically somehow and have a labelling mechanism
to encode the expectations in the consumer routines ... even if you put
a PhD student on it, I bet what we'd get back would be too complex to
be usable.

James