Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
From: Marco Elver
Date: Thu Mar 19 2026 - 10:45:42 EST
On Thu, 19 Mar 2026 at 00:31, Marco Elver <elver@xxxxxxxxxx> wrote:
>
> On Thu, Feb 26, 2026 at 04:19PM -0800, Bart Van Assche wrote:
> > On 2/26/26 12:13 PM, Marco Elver wrote:
> > > The goal of RELOC_HIDE is to make the optimizer be less aggressive.
> > > But the Thread Safety Analysis's alias analysis happens during
> > > semantic analysis and is completely detached from the optimizer, and
> > > we could potentially construct an expression that (a) lets Thread
> > > Safety Analysis figure out that __ptr is an alias to ptr, while (b)
> > > still hiding it from the optimizer. But I think we're sufficiently
> > > scared of breaking (b) that I'm not sure if this is feasible in a
> > > clean enough way that won't have other side-effects (e.g. worse
> > > codegen).
> >
> > Does the thread-safety alias analyzer assume that function calls with
> > identical inputs produce identical outputs? If so, how about changing
> > RELOC_HIDE() from a macro into an inline function? Would that be
> > sufficient to make the thread-safety checker recognize identical
> > per_cpu() expressions as identical without affecting the behavior of the
> > optimizer?
>
> The below works:
[...]
> That preserves original RELOC_HIDE intent (hide likely out-of-bounds
> pointer calculation via unsigned long cast) - GCC has its own version of
> RELOC_HIDE, so this seems to be exclusively for Clang. For codegen, the
> temporary variable was just optimized away, so I'm not sure what benefit
> that indirection had at all. So all in all that should be equivalent to
> before, and looks a lot cleaner.
>
> The reason it works for Thread Safety Analysis is that TSA's alias
> analysis strips away inner casts when resolving pointer aliases. Whereas
> if there was an intermediate non-pointer (here: ulong) variable, it
> stops.
>
> Unless there are concerns, I'll send that as a patch.
This should make the KVM code work as-is:
https://lore.kernel.org/all/20260319135245.1420780-1-elver@xxxxxxxxxx/