Re: C aggregate passing (Rust kernel policy)

[Kent Overstreet <kent.overstreet@linux.dev>]

On Tue, Feb 25, 2025 at 10:54:46AM -0800, Linus Torvalds wrote:
> On Tue, 25 Feb 2025 at 08:12, Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > I think all of this worrying about Rust not having defined its
> > aliasing model is way overblown. Ultimately, the status quo is that
> > each unsafe operation that has to do with aliasing falls into one of
> > three categories:
> >
> > * This is definitely allowed.
> > * This is definitely UB.
> > * We don't know whether we want to allow this yet.
> 
> Side note: can I please ask that the Rust people avoid the "UD" model
> as much as humanly possible?
> 
> In particular, if there is something that is undefined behavior - even
> if it's in some "unsafe" mode, please please please make the rule be
> that
> 
>  (a) either the compiler ends up being constrained to doing things in
> some "naive" code generation
> 
> or it's a clear UB situation, and
> 
>  (b) the compiler will warn about it
> 
> IOW, *please* avoid the C model of "Oh, I'll generate code that
> silently takes advantage of the fact that if I'm wrong, this case is
> undefined".
> 
> And BTW, I think this is _particularly_ true for unsafe rust. Yes,
> it's "unsafe", but at the same time, the unsafe parts are the fragile
> parts and hopefully not _so_ hugely performance-critical that you need
> to do wild optimizations.

Well, the whole point of unsafe is for the parts where the compiler
can't in general check for UB, so there's no avoiding that.

And since unsafe is required for a lot of low level data structures (vec
and lists), even though the amount of code (in LOC) that uses unsafe
should be tiny, underneath everything it's all over the place so if it
disabled aliasing optimizations that actually would have a very real
impact on performance.

HOWEVER - the Rust folks don't have the same mindset as the C folks, so
I believe (not the expert here, Rust folks please elaborate..) in
practice a lot of things that would generate UB will be able to be
caught by the compiler. It won't be like -fstrict-aliasing in C, which
was an absolute shitshow.

(There was a real lack of communication between the compiler people and
everything else when that went down, trying to foist -fstrict-aliasing
without even an escape hatch defined at the time should've been a
shooting offence).

OTOH, the stacked borrows and tree borrows work is very much rooted in
"can we define a model that works for actual code", and Rust already has
the clearly defined escape hatches/demarcation points (e.g. UnsafeCell).

> So the cases I'm talking about is literally re-ordering accesses past
> each other ("Hey, I don't know if these alias or not, but based on
> some paper standard - rather than the source code - I will assume they
> do not"),

Yep, this is treeborrows. That gives us a model of "this reference
relates to this reference" so it's finally possible to do these
optimizations without handwavy bs (restrict...).

I think the one thing that's missing w.r.t. aliasing that Rust could
maybe use is a kasan-style sanitizer, I think with treeborrows and "now
we have an actual model for aliasing optimizations" it should be possible
to write such a sanitizer. But the amount of code doing complicated
enough stuff with unsafe should really be quite small, so - shouldn't be
urgently needed. Most unsafe will be in boring FFI stuff, and there all
aliasing optimizations get turned off at the C boundary.