Re: [RFC] ->d_name accesses

[Al Viro <viro@zeniv.linux.org.uk>]

On Fri, Feb 09, 2024 at 11:10:10AM -0800, Nick Desaulniers wrote:

> I have 100% observed llvm throw out writes to objects declared as
> const where folks tried to write via "casting away the const" (since
> that's UB) which resulted in boot failures in the Linux kernel
> affecting android devices.  I can't find the commit in question at the
> moment, but seemed to have made some kind of note in it in 2020.
> https://android-review.git.corp.google.com/c/platform/prebuilts/clang/host/linux-x86/+/1201901/1/RELEASE_NOTES.md
> 
> That said, I just tried Al's union, and don't observe such optimizations.
> https://godbolt.org/z/zrj71E8W5

The really shitty part is not the missing stores; it's reordered loads.
If
	spin_lock(&dentry->d_lock);
	name = dentry->d_name.name;
	len = dentry->d_name.len;
	something(name, len);
	spin_unlock(&dentry->d_lock);
has the compiler go "->d_name is const, so I can bloody well move
the load before that spin_lock() call", we really have a problem.

Can it reorder the loads of const member wrt e.g. barrier()?  If
that's the case, this approach is no-go and accessor is the only
feasible alternative.