From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4003283FE3 for ; Wed, 18 Mar 2026 23:31:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773876687; cv=none; b=ORuGN+ybE5SkQG5fqpm1YUblVhgOTXgU3yWNa52I59lhPXMj7V4HwhfKgIIP2HkOsDsMJKOG4xySfo4UVNZi7Cu/sAxyeuQQdsPPznZHZd7DJ5isL0xdWeCOI394HUVTKCRGDonEDcy+FQZEuKL5GXTLNRh5HFDkS6vDh6sKgyg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773876687; c=relaxed/simple; bh=TsTEW844cnAtWu7hlRH8Q6V/4AkhN4EyndxafojPyvM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XRi/z3GAjPVjDtZRnE1UHNYnvxi/PrKsXedE8BC0bpJgTey5DLAr4BKU9dNkNEvNg1LGe7axu5jsDhHuajEFPevyqaOaeSjPE/TDXgq1xdpsUfIO10V2oXMjM4DNmZS+5gaPB0844gij2UF/1qVXYUH9bzUJyDpbyqAOj4+NZnQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Nns4xFXh; arc=none smtp.client-ip=209.85.221.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Nns4xFXh" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-43b4d734678so319451f8f.1 for ; Wed, 18 Mar 2026 16:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1773876684; x=1774481484; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=PPESgE6Nig2k963E/tBvH++66JZV+AKWoFevLTVVc+c=; b=Nns4xFXhRKW1eFzlJnanrDrfvDAUl/SE7XnCMGnnzT4hgWyu3E2C6nUP3h6f+PeOQc FUda/XW7fVJ3Xj9sHMrv6nOdolfUKw9345qSNBo/FGr5YNinWCQmhskjQYCNoKWrGD2i hX0ivqEonMW670AZhY973S/6VrPHKJXs8NcwrAlxWI1v814AFhdG5gDnC3ZfQJWRECGa qhesgkf7UbvSktSUH22JcXnrzBWP+z+p3Ib3T33tvRhsoHbyQ9ko1IxLANPrjCdy6OK7 Ea87B/iJC4L4T0bEtzuEvhNyOZpPDPKjGoclHmPzJPZGwKgfhXBqwleVFmennMs+Bvxk 3AbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773876684; x=1774481484; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=PPESgE6Nig2k963E/tBvH++66JZV+AKWoFevLTVVc+c=; b=RFxd7XJXrOF0wrFgjffxkXv6AEYVYh72gK9qUy16kwf1wPFXJ/QJRMWqjkZO1gYyom eIswC1nme7IKDlsIY6HF7FzWfRG3o75cXHHNnFTFKje75K/MiJ10LU8ICINsjc/AGMN3 1GUKyYeBejHFjW9Pwh60YJsFNLXNEVgsgsvNwgYbMzAqf7MIhCN2Q2dLzmhlT3VURUVm +xuvsSZIELXoo1XORbIjqFmYoD8oJPdxqw47v+rTE889nfb00qpAIpMFKY9EvZRtjQu0 fNJ1U05ijAFN/8ad3qLrKuoRQFNwFeF6lPdSTAXgStNlF/0xr4cR3/Jj596rrmK5HAEp tw7A== X-Forwarded-Encrypted: i=1; AJvYcCUGem9nzBTzBilpMEbf0WAONBSZSFlLEDGeLH+D4o24kSE2N49lD5nT3En+mdfgkoyY6VLZcWwPUW2Anvw=@vger.kernel.org X-Gm-Message-State: AOJu0YyPqLmU1EZjz4NclfFK8KQGzVhqJyhlAPdkzqSmuv6dpBNNzyOo a1WUXglipFHY/ny78atVZHfhKxtzpChNKgqJE5DoDi4Rr9CzM1ECZomy6a9/UubnNg== X-Gm-Gg: ATEYQzwpmVNZKmKmsJy3bSm1TGgDCt4vWYO0+Uhg7bYd5HDBpWoyDbRrxUeWU+FIlVF cY23PIfwzYH2ZJwkVgInnMpCxYQu2iLWYWltOdNYhoKQ7ThitV2O8rhlTLsY3rBRndbLummo5lZ sadaswBV0kCpEJwxep0EMZ/WtIir4QXvravkgvtR3Ox9PBKtLp6N+z3YCUT7CRBLwNo9mLALosJ CJns+jL/OSk12w2jyh8BDtQYvGQj1AqCbsQlP3WvlA9aD3CgU+EgTkSJVrNEOomPQy1SE5nU+OZ jJduutIPm20wtPrLbHZ5r+2W7H4W19Lx32fHz9QyoKqNjJKE91ItI3etmkc5h0UGujuGmgM8BEK 6P6S5gDilj/RqoyaOfHwaEgRFlWfyeVVz39dneoqwTFX3jfeoso4WdEMRwBX1xiTWckmDJBkcXO FOXe//UaBMjxOG4utrRbEvF6egL3pD7oHbwzCaDupSt/YDHOBm/KC8thvky2VO X-Received: by 2002:a05:6000:26c8:b0:43b:3e0b:721a with SMTP id ffacd0b85a97d-43b527c8099mr8704888f8f.38.1773876683581; Wed, 18 Mar 2026 16:31:23 -0700 (PDT) Received: from elver.google.com ([2a00:79e0:2834:9:90c2:7bc8:af6b:77c7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b518a3dedsm10785914f8f.36.2026.03.18.16.31.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Mar 2026 16:31:22 -0700 (PDT) Date: Thu, 19 Mar 2026 00:31:15 +0100 From: Marco Elver To: Bart Van Assche Cc: Sean Christopherson , Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , linux-kernel@vger.kernel.org, Christoph Hellwig , Steven Rostedt , Nick Desaulniers , Nathan Chancellor , Kees Cook , Jann Horn , Paolo Bonzini , kvm@vger.kernel.org Subject: Re: [PATCH 01/62] kvm: Make pi_enable_wakeup_handler() easier to analyze Message-ID: References: <20260223215118.2154194-1-bvanassche@acm.org> <20260223215118.2154194-2-bvanassche@acm.org> <7a22294b-1150-4c55-a95a-ea918cfb9b76@acm.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.13 (2024-03-09) 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.