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: <d465e17bfc45e02b2bbd68a4235cc1c7fd7500e1.camel@tugraz.at>
Date: Fri, 28 Feb 2025 09:32:52 +0100
From: Martin Uecker <uecker@...raz.at>
To: Ralf Jung <post@...fj.de>, Linus Torvalds
 <torvalds@...ux-foundation.org>,  "Paul E. McKenney" <paulmck@...nel.org>
Cc: Alice Ryhl <aliceryhl@...gle.com>, Ventura Jack
 <venturajack85@...il.com>,  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)

Am Freitag, dem 28.02.2025 um 09:08 +0100 schrieb Ralf Jung:

> 
> (From a different email)
> > It sounds you want to see the semantics strengthened in case
> > of a data race from there being UB to having either the old
> > or new value being visible to another thread, where at some
> > point this could change but needs to be consistent for a
> > single access as expressed in the source code.
> 
> This would definitely impact optimizations of purely sequential code. Maybe that 
> is a price worth paying, but one of the goals of the C++ model was that if you 
> don't use threads, you shouldn't pay for them. Disallowing rematerialization in 
> entirely sequential code (just one of the likely many consequences of making 
> data races not UB) contradicts that goal. 

This is the feedback I now also got from GCC, i.e. there are cases where
register allocator would indeed rematerialize a load and they think this is
reasonable.

> Given that even in highly concurrent 
> programs, most accesses are entirely sequential, it doesn't seem unreasonable to 
> say that the exceptional case needs to be marked in the program (especially if 
> you have a type system which helps ensure that you don't forget to do so).

Martin