Message-ID: <CAFJgqgREAj-eP-d244WpqO-9H48ajZh83AxE31GqoONZ=DJe-g@mail.gmail.com>
Date: Tue, 25 Feb 2025 10:21:28 -0700
From: Ventura Jack <venturajack85@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	Kent Overstreet <kent.overstreet@...ux.dev>, 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 9:12 AM Alice Ryhl <aliceryhl@...gle.com> wrote:
>
> On Sun, Feb 23, 2025 at 4:30 PM Ventura Jack <venturajack85@...il.com> wrote:
> >
> > Just to be clear and avoid confusion, I would
> > like to clarify some aspects of aliasing.
> > In case that you do not already know about this,
> > I suspect that you may find it very valuable.
> >
> > I am not an expert at Rust, so for any Rust experts
> > out there, please feel free to point out any errors
> > or mistakes that I make in the following.
> >
> > The Rustonomicon is (as I gather) the semi-official
> > documentation site for unsafe Rust.
> >
> > Aliasing in C and Rust:
> >
> > C "strict aliasing":
> > - Is not a keyword.
> > - Based on "type compatibility".
> > - Is turned off by default in the kernel by using
> >     a compiler flag.
> >
> > C "restrict":
> > - Is a keyword, applied to pointers.
> > - Is opt-in to a kind of aliasing.
> > - Is seldom used in practice, since many find
> >     it difficult to use correctly and avoid
> >     undefined behavior.
> >
> > Rust aliasing:
> > - Is not a keyword.
> > - Applies to certain pointer kinds in Rust, namely
> >     Rust "references".
> >     Rust pointer kinds:
> >     https://doc.rust-lang.org/reference/types/pointer.html
> > - Aliasing in Rust is not opt-in or opt-out,
> >     it is always on.
> >     https://doc.rust-lang.org/nomicon/aliasing.html
> > - Rust has not defined its aliasing model.
> >     https://doc.rust-lang.org/nomicon/references.html
> >         "Unfortunately, Rust hasn't actually
> >         defined its aliasing model.
> >         While we wait for the Rust devs to specify
> >         the semantics of their language, let's use
> >         the next section to discuss what aliasing is
> >         in general, and why it matters."
> >     There is active experimental research on
> >     defining the aliasing model, including tree borrows
> >     and stacked borrows.
> > - The aliasing model not being defined makes
> >     it harder to reason about and work with
> >     unsafe Rust, and therefore harder to avoid
> >     undefined behavior/memory safety bugs.
>
> 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.
>
> The full aliasing model that they want would eliminate the third
> category. But for practical purposes you just stay within the first
> subset and you will be happy.
>
> Alice

Is there a specification for aliasing that defines your first bullet
point, that people can read and use, as a kind of partial
specification? Or maybe a subset of your first bullet point, as a
conservative partial specification? I am guessing that stacked
borrows or tree borrows might be useful for such a purpose.
But I do not know whether either of stacked borrows or tree
borrows have only false positives, only false negatives, or both.

For Rust documentation, I have heard of the official
documentation websites at

    https://doc.rust-lang.org/book/
    https://doc.rust-lang.org/nomicon/

And various blogs, forums and research papers.

If there is no such conservative partial specification for
aliasing yet, I wonder if such a conservative partial
specification could be made with relative ease, especially if
it is very conservative, at least in its first draft. Though there
is currently no specification of the Rust language and just
one major compiler.

I know that Java defines an additional conservative reasoning
model for its memory model that is easier to reason about
than the full memory model, namely happens-before
relationship. That conservative reasoning model is taught in
official Java documentation and in books.

On the topic of difficulty, even if there was a full specification,
it might still be difficult to work with aliasing in unsafe Rust.
For C "restrict", I assume that "restrict" is fully specified, and
C developers still typically avoid "restrict". And for unsafe
Rust, the Rust community helpfully encourages people to
avoid unsafe Rust when possible due to its difficulty.

Best, VJ.

Powered by blists - more mailing lists