Message-ID: <ea961d5d824576753b614fe32cb2837403eac8d7.camel@tugraz.at>
Date: Wed, 26 Feb 2025 21:22:23 +0100
From: Martin Uecker <uecker@...raz.at>
To: Ralf Jung <post@...fj.de>, Ventura Jack <venturajack85@...il.com>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>, Miguel Ojeda
	 <miguel.ojeda.sandonis@...il.com>, Gary Guo <gary@...yguo.net>, 
	torvalds@...ux-foundation.org, 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, rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)


Am Mittwoch, dem 26.02.2025 um 20:23 +0100 schrieb Ralf Jung:
> Hi all,
> 
> > > > But it is much more significant for Rust than for C, at least in
> > > > regards to C's "restrict", since "restrict" is rarely used in C, while
> > > > aliasing optimizations are pervasive in Rust. For C's "strict aliasing",
> > > > I think you have a good point, but "strict aliasing" is still easier to
> > > > reason about in my opinion than C's "restrict". Especially if you
> > > > never have any type casts of any kind nor union type punning.
> > > 
> > > Is it easier to reason about? At least GCC got it wrong, making no-aliasing
> > > assumptions that are not justified by most people's interpretation of the model:
> > > https://bugs.llvm.org/show_bug.cgi?id=21725
> > > (But yes that does involve unions.)
> > 
> > Did you mean to say LLVM got this wrong?   As far as I know,
> > the GCC TBBA code is more correct than LLVMs.  It gets
> > type-changing stores correct that LLVM does not implement.
> 
> Oh sorry, yes that is an LLVM bug link. I mixed something up. I could have sworn 
> there was a GCC bug, but I only found 
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359> which has been fixed.
> There was some problem with strong updates, i.e. the standard permits writes 
> through a `float*` pointer to memory that aliases an `int*`. The C aliasing 
> model only says it is UB to read data at the wrong type, but does not talk about 
> writes changing the type of memory.
> Martin, maybe you remember better than me what that issue was / whether it is 
> still a problem?

There are plenty of problems ;-)  But GCC mostly gets the type-changing
stores correct as specified in the C standard.  The bugs related to this
that I tracked got fixed. Clang still does not implement this as specified.
It implements the C++ model which does not require type-changing stores
to work (but I am not an expert on the C++ side).   To be fair, there
was also incorrect guidance from WG14 at some point that added to the
confusion.

So I think for C one could use GCC with strict aliasing if one is careful
and observes the usual rules, but I would certainly recommend against
doing this for Clang. 

What both compilers still get wrong are all the corner cases related to
provenance including the integer-pointer roundtrips.
The LLVM maintainer said they are going to fix the later soon, so
there is some hope on this side.

> 
> > > > > So, the situation for Rust here is a lot better than it is in C. Unfortunately,
> > > > > running kernel code in Miri is not currently possible; figuring out how to
> > > > > improve that could be an interesting collaboration.
> > > > 
> > > > I do not believe that you are correct when you write:
> > > > 
> > > >       "Unlike sanitizers, Miri can actually catch everything."
> > > > 
> > > > Critically and very importantly, unless I am mistaken about MIRI, and
> > > > similar to sanitizers, MIRI only checks with runtime tests. That means
> > > > that MIRI will not catch any undefined behavior that a test does
> > > > not encounter. If a project's test coverage is poor, MIRI will not
> > > > check a lot of the code when run with those tests. Please do
> > > > correct me if I am mistaken about this. I am guessing that you
> > > > meant this as well, but I do not get the impression that it is
> > > > clear from your post.
> > > 
> > > Okay, I may have misunderstood what you mean by "catch everything". All
> > > sanitizers miss some UB that actually occurs in the given execution. This is
> > > because they are inserted in the pipeline after a bunch of compiler-specific
> > > choices have already been made, potentially masking some UB. I'm not aware of a
> > > sanitizer for sequence point violations. I am not aware of a sanitizer for
> > > strict aliasing or restrict. I am not aware of a sanitizer that detects UB due
> > > to out-of-bounds pointer arithmetic (I am not talking about OOB accesses; just
> > > the arithmetic is already UB), or UB due to violations of "pointer lifetime end
> > > zapping", or UB due to comparing pointers derived from different allocations. Is
> > > there a sanitizer that correctly models what exactly happens when a struct with
> > > padding gets copied? The padding must be reset to be considered "uninitialized",
> > > even if the entire struct was zero-initialized before. Most compilers implement
> > > such a copy as memcpy; a sanitizer would then miss this UB.
> > 
> > Note that reading padding bytes in C is not UB. Regarding
> > uninitialized variables, only automatic variables whose address
> > is not taken is UB in C.   Although I suspect that compilers
> > have compliance isues here.
> 
> Hm, now I am wondering how clang is compliant here. To my knowledge, padding is 
> effectively reset to poison or undef on a copy (due to SROA), and clang marks 
> most integer types as "noundef", thus making it UB to ever have undef/poison in 
> such a value.

I haven't kept track with this, but I also do not believe that
Clang is conforming to the C standard, but again follows C++ rules
which has more UB.   I am also not entirely sure GCC gets this
completely right though.

Martin


> 
> Kind regards,
> Ralf
> 
> > 
> > But yes, it sanitizers are still rather poor.
> 
> 
> 
> > 
> > Martin
> > 
> > > 
> > > In contrast, Miri checks for all the UB that is used anywhere in the Rust
> > > compiler -- everything else would be a critical bug in either Miri or the compiler.
> > > But yes, it only does so on the code paths you are actually testing. And yes, it
> > > is very slow.
> > > 
> > > Kind regards,
> > > Ralf
> > > 
> > 
> 

Powered by blists - more mailing lists