Re: Rust kernel policy

[Geert Uytterhoeven]

Hi James,

On Wed, 19 Feb 2025 at 15:20, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 2025-02-19 at 11:05 +0300, Dan Carpenter wrote:
> > On Tue, Feb 18, 2025 at 08:08:18AM -0800, Christoph Hellwig wrote:
> > > But that also shows how core maintainers are put off by trivial
> > > things like checking for integer overflows or compiler enforced
> > > synchronization (as in the clang thread sanitizer).
> > > How are we're going to bridge the gap between a part of the kernel
> > > that is not even accepting relatively easy rules for improving
> > > safety vs another one that enforces even strong rules.
> >
> > Yeah.  It's an ironic thing...
> >
> >         unsigned long total = nr * size;
> >
> >         if (nr > ULONG_MAX / size)
> >                 return -EINVAL;
> >
> > In an ideal world, people who write code like that should receive a
> > permanent ban from promoting Rust.
>
> I look at most of the bugfixes flowing through subsystems I watch and a
> lot of them are in error legs.  Usually around kfree cockups (either
> forgetting or freeing to early).  Could we possibly fix a lot of this
> by adopting the _cleanup_ annotations[1]?  I've been working in systemd
> code recently and they seem to make great use of this for error leg
> simplification.

Sure!
https://elixir.bootlin.com/linux/v6.13.3/source/include/linux/cleanup.h

Unfortunately these may cause a new bunch of cockups, due to
forgetting to call no_free_ptr() when needed...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds