Message-ID: <hofm7mo46jzkevpr6fkqe2jnl3zrp5uxdux457hli3ywkneaij@yhhibsnuqfny>
Date: Tue, 25 Feb 2025 18:34:42 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Alice Ryhl <aliceryhl@...gle.com>, 
	Ventura Jack <venturajack85@...il.com>, Gary Guo <gary@...yguo.net>, airlied@...il.com, 
	boqun.feng@...il.com, david.laight.linux@...il.com, ej@...i.de, 
	gregkh@...uxfoundation.org, hch@...radead.org, hpa@...or.com, ksummit@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, miguel.ojeda.sandonis@...il.com, rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)

On Tue, Feb 25, 2025 at 01:24:42PM -0800, Linus Torvalds wrote:
> On Tue, 25 Feb 2025 at 12:55, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> >
> > The problem isn't that "pointer aliasing is fundamentally unsafe and
> > dangerous and therefore the compiler just has to stay away from it
> > completely" - the problem has just been the lack of a workable model.
> 
> It's not entirely clear that a workable aliasing model exists outside
> of "don't assume lack of aliasing".
> 
> Because THAT is the only truly workable model I know of. It's the one
> we use in the kernel, and it works just fine.
> 
> For anything else, we only have clear indications that _unworkable_
> models exist.
> 
> We know type aliasing is garbage.

The C people thinking casting to a union was a workable escape hatch was
hilarious, heh. But now we've got mem::transmute(), i.e. that can (and
must be) annotated to the compiler.

> We know "restrict" doesn't work very well: part of that is that it's
> fairly cumbersome to use, but a large part of that is that a pointer
> will be restricted in one context and not another, and it's just
> confusing and hard to get right.

And it only works at all in the simplest of contexts...

> What we do know works is hard rules based on provenance. All compilers
> will happily do sane alias analysis based on "this is a variable that
> I created, I know it cannot alias with anything else, because I didn't
> expose the address to anything else".

Yep. That's what all this is based on.

> So *provenance*-based aliasing works, but it only works in contexts
> where you can see the provenance. Having some way to express
> provenance across functions (and not *just* at allocation time) might
> be a good model.

We have that! That's exactly what lifetime annotations are.

We don't have that for raw pointers, but I'm not sure that would ever be
needed since you use raw pointers in small and localized places, and a
lot of the places where aliasing comes up in C (e.g. memmove()) you
express differently in Rust, with slices and indices.

(You want to drop from references to raw pointers at the last possible
moment).

And besides, a lot of the places where aliasing comes up in C are
already gone in Rust, there's a lot of little things that help.
Algebraic data types are a big one, since a lot of the sketchy hackery
that goes on in C where aliasing is problematic is just working around
the lack of ADTs.

> But in the absence of knowledge, and in the absence of
> compiler-imposed rules (and "unsafe" is by *definition* that absence),
> I think the only rule that works is "don't assume they don't alias".

Well, for the vast body of Rust code that's been written that just
doesn't seem to be the case, and I think it's been pretty well
demonstrated that anything we can do in C, we can also do just as
effectively in Rust.

treeborrow is already merged into Miri - this stuff is pretty far along.

Now if you're imagining directly translating all the old grotty C code I
know you have in your head - yeah, that won't work. But we already knew
that.

Powered by blists - more mailing lists