public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Sean Christopherson <seanjc@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
	linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Kees Cook <kees@kernel.org>, Jann Horn <jannh@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze
Date: Thu, 19 Mar 2026 00:31:15 +0100	[thread overview]
Message-ID: <abs1w28YCs8Qj71w@elver.google.com> (raw)
In-Reply-To: <e3946223-4543-4a76-a328-9c6865e95192@acm.org>

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:

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index af16624b29fd..cb2f6050bdf7 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -149,10 +149,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
 #endif
 
 #ifndef RELOC_HIDE
-# define RELOC_HIDE(ptr, off)					\
-  ({ unsigned long __ptr;					\
-     __ptr = (unsigned long) (ptr);				\
-    (typeof(ptr)) (__ptr + (off)); })
+# define RELOC_HIDE(ptr, off) ((typeof(ptr))((unsigned long)(ptr) + (off)))
 #endif
 
 #define absolute_pointer(val)	RELOC_HIDE((void *)(val), 0)

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.

  reply	other threads:[~2026-03-18 23:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260223215118.2154194-1-bvanassche@acm.org>
2026-02-23 21:50 ` [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze Bart Van Assche
2026-02-24 18:20   ` Sean Christopherson
2026-02-24 19:25     ` Bart Van Assche
2026-02-26 17:47       ` Sean Christopherson
2026-02-26 20:13         ` Marco Elver
2026-02-27  0:19           ` Bart Van Assche
2026-03-18 23:31             ` Marco Elver [this message]
2026-03-19 14:43               ` Marco Elver
2026-02-26 22:36         ` Bart Van Assche
2026-02-26 22:41           ` Sean Christopherson
     [not found] <20260223220102.2158611-1-bart.vanassche@linux.dev>
2026-02-23 22:00 ` Bart Van Assche
     [not found] <20260223214950.2153735-1-bvanassche@acm.org>
2026-02-23 21:48 ` Bart Van Assche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abs1w28YCs8Qj71w@elver.google.com \
    --to=elver@google.com \
    --cc=boqun@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=hch@lst.de \
    --cc=jannh@google.com \
    --cc=kees@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=seanjc@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox