linux-kernel - Re: C aggregate passing (Rust kernel policy)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <czke6xumgufksyvu7xgin2ygn2jx6uvgtgwfknafq4s4migccz@aih2ptkzw3jx>
Date: Thu, 27 Feb 2025 13:13:40 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, Martin Uecker <uecker@...raz.at>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Ralf Jung <post@...fj.de>, 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 Thu, Feb 27, 2025 at 09:35:10AM -0800, Paul E. McKenney wrote:
> On Thu, Feb 27, 2025 at 09:29:49AM -0500, Steven Rostedt wrote:
> > On Thu, 27 Feb 2025 07:56:47 +0100
> > Martin Uecker <uecker@...raz.at> wrote:
> > 
> > > Observable is I/O and volatile accesses.  These are things considered
> > > observable from the outside of a process and the only things an
> > > optimizer has to preserve.  
> > > 
> > > Visibility is related to when stores are visible to other threads of
> > > the same process. But this is just an internal concept to give
> > > evaluation of expressions semantics in a multi-threaded 
> > > program when objects are accessed from different threads. But 
> > > the compiler is free to change any aspect of it, as  long as the 
> > > observable behavior stays the same.
> > > 
> > > In practice the difference is not so big for a traditional
> > > optimizer that only has a limited local view and where
> > > "another thread" is basically part of the "outside world".
> > 
> > So basically you are saying that if the compiler has access to the entire
> > program (sees the use cases for variables in all threads) that it can
> > determine what is visible to other threads and what is not, and optimize
> > accordingly?
> > 
> > Like LTO in the kernel?
> 
> LTO is a small step in that direction.  In the most extreme case, the
> compiler simply takes a quick glance at the code and the input data and
> oracularly generates the output.
> 
> Which is why my arguments against duplicating atomic loads have been
> based on examples where doing so breaks basic arithmetic.  :-/

Please tell me that wasn't something that seriously needed to be said...