From nobody Mon Feb 9 07:22:06 2026 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (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 ADCCC30EF9A for ; Fri, 30 Jan 2026 13:30:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769779816; cv=none; b=a9vBIdMcWMFcxnTvyc1HgChEK8YEsLrpkI3EG3D0YSQpY2CBemp9FwkVwUzLcs7QGnkskzdqCSn3Bo1O3R69PZ02MPNXOcehw0NT672/df9N9wAAdUzWRX0QmlgL+gKw9QTK8CP5ysSlwkLxqtJqqvNF1IwY4+0gghnzF5Y60sA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769779816; c=relaxed/simple; bh=T4dPZtG1oh8ppeo/D7aOCiu7eQficsG0EdVSGiJeJNI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=MTvFA2NzPLi4zczyqTqROGxZcmD6K7P0E1NpGmqRtJcmyuKKjbBOcDs0ujGT4eK+a5O7+TP81JMQqC6YGh+ZTYXOQAWtG8hs0HCuT/zg8QM0dfWpTDSZjK0j2zln4chs0/kM+Ez2huuFQT9ojlb5JK1c1d7c4JhyuUcVfJMbzxQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--elver.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ZT+oddGn; arc=none smtp.client-ip=209.85.128.73 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=flex--elver.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZT+oddGn" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-480711d09f1so34382875e9.0 for ; Fri, 30 Jan 2026 05:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769779813; x=1770384613; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=EIZZgTWN+WVkGCe2DzZUi2LmQSShjbtn6Lr33NLpRdc=; b=ZT+oddGn6nO6KfS3mkRwqNfPmD3kf6tfALKXEEX6Dq4j238QromjIPEUeFn+sfCkcq V6GGwxS0UPLI+Ucd+ejYe4shR8VZSzibzCin/ChG5AjM9PeJAUuG+fgaQVcGdqh3az5D rQgAdw4pRRtoM6tu9DhsJlvEI15UbuoUWEflI5fo0QFzDwpeXGjjGTZvY6jI8b0vR/DK O6Xrm2fSo9CX3g1UrzP/SDuWowGekHZ3+1Clxlhr2P6Ie7SbBWuJlroDCOPSfys44v1U IzP+pnrRsD0fG6OtfWi6Vl3UHTjkTVTwg1kwRG9Vpn5tebkxcHZx1hiLP55QLj5xwAp8 pvgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769779813; x=1770384613; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EIZZgTWN+WVkGCe2DzZUi2LmQSShjbtn6Lr33NLpRdc=; b=Y5MlEZb8CHj+SFbNLdYcj11m0+nW9aVXrQx2UsDWsEdx0Fv0nUatTMBD6/a7IEFzuG bonTVbBcxdLyGeAoY0xEbp5k6eyOWVUGugIOhWGkEdDDybki1CyWJRiQNJh/smLwDd0S k+9ibjpWVaG0PBmjeQQk7R8Gq3MY3KnSyp4qz+66ccarL8UBdzTzN6qkI7WmEhiAHmuG MVB9LTe2s4vTyOeoOmfS190DHLm51fna8VVme9BuRC2DzFECFXwMRFB1HZfguW4piLk5 XsYP2YQ767OvKcAB9oL8SHU3yWqrfLVj0XJEPInlOxZrGxyttnalo1vXaJ+3D5vYvOIL DyOg== X-Forwarded-Encrypted: i=1; AJvYcCU7QAUYizxAUl8+jqgCQueJT6AoilAexaEuUEY9UngA4zrj1jE4+WIjoiNl3irzfIsL/WEe4wi9+IOS6Ic=@vger.kernel.org X-Gm-Message-State: AOJu0YwVHV2GDqfqtkr1f584bq43QilsZPyXNtkacsGeDD6gbiTXTkxV BAqWzpywHzONQ8LuaROsgf6noWoMWDb7zBoMvCgU6RkollgHXPnnmJBA7HouWvw6gDYNEPNQ8lk /Sg== X-Received: from wmot9.prod.google.com ([2002:a05:600c:4509:b0:477:7aa2:99cb]) (user=elver job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:c4a3:b0:480:6c75:ddce with SMTP id 5b1f17b1804b1-482db49da16mr40851245e9.33.1769779813044; Fri, 30 Jan 2026 05:30:13 -0800 (PST) Date: Fri, 30 Jan 2026 14:28:26 +0100 In-Reply-To: <20260130132951.2714396-1-elver@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260130132951.2714396-1-elver@google.com> X-Mailer: git-send-email 2.53.0.rc1.225.gd81095ad13-goog Message-ID: <20260130132951.2714396-4-elver@google.com> Subject: [PATCH v3 3/3] arm64, compiler-context-analysis: Permit alias analysis through __READ_ONCE() with CONFIG_LTO=y From: Marco Elver To: elver@google.com, Peter Zijlstra , Will Deacon Cc: Ingo Molnar , Thomas Gleixner , Boqun Feng , Waiman Long , Bart Van Assche , llvm@lists.linux.dev, David Laight , Catalin Marinas , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel test robot , Boqun Feng Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When enabling Clang's Context Analysis (aka. Thread Safety Analysis) on kernel/futex/core.o (see Peter's changes at [1]), in arm64 LTO builds we could see: | kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->loc= k_ptr' is still held at the end of function [-Wthread-safety-analysis] | 982 | } | | ^ | kernel/futex/core.c:976:2: note: spinlock acquired here | 976 | spin_lock(lock_ptr); | | ^ | kernel/futex/core.c:982:1: warning: expecting spinlock 'q->lock_ptr' to b= e held at the end of function [-Wthread-safety-analysis] | 982 | } | | ^ | kernel/futex/core.c:966:6: note: spinlock acquired here | 966 | void futex_q_lockptr_lock(struct futex_q *q) | | ^ | 2 warnings generated. Where we have: extern void futex_q_lockptr_lock(struct futex_q *q) __acquires(q->lock_ptr= ); .. void futex_q_lockptr_lock(struct futex_q *q) { spinlock_t *lock_ptr; /* * See futex_unqueue() why lock_ptr can change. */ guard(rcu)(); retry: >> lock_ptr =3D READ_ONCE(q->lock_ptr); spin_lock(lock_ptr); ... } At the time of the above report (prior to removal of the 'atomic' flag), Clang Thread Safety Analysis's alias analysis resolved 'lock_ptr' to 'atomic ? __u.__val : q->lock_ptr' (now just '__u.__val'), and used this as the identity of the context lock given it cannot "see through" the inline assembly; however, we want 'q->lock_ptr' as the canonical context lock. While for code generation the compiler simplified to '__u.__val' for pointers (8 byte case -> 'atomic' was set), TSA's analysis (a) happens much earlier on the AST, and (b) would be the wrong deduction. Now that we've gotten rid of the 'atomic' ternary comparison, we can return '__u.__val' through a pointer that we initialize with '&x', but then update via a pointer-to-pointer. When READ_ONCE()'ing a context lock pointer, TSA's alias analysis does not invalidate the initial alias when updated through the pointer-to-pointer, and we make it effectively "see through" the __READ_ONCE(). Code generation is unchanged. Link: https://lkml.kernel.org/r/20260121110704.221498346@infradead.org [1] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601221040.TeM0ihff-lkp@int= el.com/ Cc: Peter Zijlstra Tested-by: Boqun Feng Signed-off-by: Marco Elver Reviewed-by: David Laight --- v3: * Use 'typeof(*__ret)'. * Commit message. v2: * Rebase. --- arch/arm64/include/asm/rwonce.h | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonc= e.h index 42c9e8429274..b7de74d4bf07 100644 --- a/arch/arm64/include/asm/rwonce.h +++ b/arch/arm64/include/asm/rwonce.h @@ -45,8 +45,12 @@ */ #define __READ_ONCE(x) \ ({ \ - typeof(&(x)) __x =3D &(x); \ - union { __rwonce_typeof_unqual(*__x) __val; char __c[1]; } __u; \ + auto __x =3D &(x); \ + auto __ret =3D (__rwonce_typeof_unqual(*__x) *)__x; \ + /* Hides alias reassignment from Clang's -Wthread-safety. */ \ + auto __retp =3D &__ret; \ + union { typeof(*__ret) __val; char __c[1]; } __u; \ + *__retp =3D &__u.__val; \ switch (sizeof(x)) { \ case 1: \ asm volatile(__LOAD_RCPC(b, %w0, %1) \ @@ -71,7 +75,7 @@ default: \ __u.__val =3D *(volatile typeof(*__x) *)__x; \ } \ - __u.__val; \ + *__ret; \ }) =20 #endif /* !BUILD_VDSO */ --=20 2.53.0.rc1.225.gd81095ad13-goog