From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 498A1E6BF0E for ; Fri, 30 Jan 2026 13:30:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:Cc:To:From: Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=EIZZgTWN+WVkGCe2DzZUi2LmQSShjbtn6Lr33NLpRdc=; b=P3M1qPIYgXlfRg8mhX4j0lzsns pn1edzjai8r6BVvhEmIL2TCvoD7Cwvd6JVjE6mkO5dfVSvud5HaUk8jOYef5z8N/NAIQRIs/eqcvy rhfGsMtl9levpME4hxRWg5HcyK2wToLMhOIsEWvttupEn3vh85pwg3ds+qCIq0AwZnLGuGwBnZSzh cPB/x+HtMZbQ5Jk+S/y0rE/Z0n9n2/UmXr07k6L69GE+6lSpX6k3DubF6pXkllJw9wQ2MZu2TRvy4 D8ig4Vabie780nDg/6ptqwKfuctI+oxhBL/1BS4lB0OJJSy9o1Exmy3J50XkjodJblUwhluSYL9w8 3eTjpdsw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vloZu-00000001XGf-0B0g; Fri, 30 Jan 2026 13:30:26 +0000 Received: from mail-wm1-x349.google.com ([2a00:1450:4864:20::349]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vloZj-00000001XCd-250S for linux-arm-kernel@lists.infradead.org; Fri, 30 Jan 2026 13:30:16 +0000 Received: by mail-wm1-x349.google.com with SMTP id 5b1f17b1804b1-47ee33324e8so23323985e9.1 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=lists.infradead.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=zBT/iHmYiJU11BAPJliZc5egxlV8T9UTf2xytYtP+eZTABsrw2JgiPrCHK/Mw2np8s zKVcRVTsxCcTiIaBG7OhRK5aqcN69VYPxnwSmFAw0F81rdiGdGNmES2rq1ByvKjdAV4K jQ4JcF7DQueCn9JBhymxlCBRUGOQ0ZdhGk0OUGAWjS1lfJL91QcNWY1ig1ig3ln6y8bk psW5vhyGHutTDBxzNH+dtTQHNA3HSHTSam9n8VpN1CNIGztL73p+hKGRaldOJc8pdLpa DSi0M9rO/qgFVgFxnDKj/lNcDVq2gc6kMM3dNPXOgbcPcHOe7VNraP2c5OPhs/sxCTN0 ZbjA== 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=ZuyoUclTK8RuRynhq9+l5CM/iQG/dRjtVPzjHkCcd6qPlW/FayX0X9KiOUAo4Gj64C eW3cuXwmIWQiSOAk/Eg1toz8ScWyL/T6cyahgSZxtcqZSgbe8k6tqX9dhtd2M6McpYUb jRHWrPWOVsmGvOdCzwPGAJIyd1FvdHQyPNMIwr3wGbWLRQe+4v7PH48t3fO2AiGAKvJc DKxAfsMOEYgt61AtYYkDG264PUUIKyVr++6viUoi6dQneb+yAJkV+GnKI+KtZvpSVu51 ZT6hE9Dr+xgVwN8AmhfP3Qdf0VecPeyLLimzUtMBHd1pWVGITDe3iVDL4iqFYW4hM881 saAg== X-Forwarded-Encrypted: i=1; AJvYcCWCR2rXn1HOsUPnct4w7AwWScmb6nlX0DKoAtQ8y/WdI3rGcCX0vchWNTG1aRiCrLTvIBxZkIbtbVCemsBjzXqM@lists.infradead.org X-Gm-Message-State: AOJu0YzfQ68s49ZTTvevp5CwDSsxxUj6s1h2aXGn4QKY7Ux1p69vCPv2 rXOPRES0ItBeYqLlHYjwoF43n8Yv2IKw9ZtRvdHNYyZGUwgusoVs4imW17hQQqpNZpMzAX6xZKc zfg== 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> 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-Type: text/plain; charset="UTF-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260130_053015_550479_268B5B47 X-CRM114-Status: GOOD ( 18.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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->lock_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 be 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 = 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@intel.com/ Cc: Peter Zijlstra Tested-by: Boqun Feng Signed-off-by: Marco Elver --- 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/rwonce.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 = &(x); \ - union { __rwonce_typeof_unqual(*__x) __val; char __c[1]; } __u; \ + auto __x = &(x); \ + auto __ret = (__rwonce_typeof_unqual(*__x) *)__x; \ + /* Hides alias reassignment from Clang's -Wthread-safety. */ \ + auto __retp = &__ret; \ + union { typeof(*__ret) __val; char __c[1]; } __u; \ + *__retp = &__u.__val; \ switch (sizeof(x)) { \ case 1: \ asm volatile(__LOAD_RCPC(b, %w0, %1) \ @@ -71,7 +75,7 @@ default: \ __u.__val = *(volatile typeof(*__x) *)__x; \ } \ - __u.__val; \ + *__ret; \ }) #endif /* !BUILD_VDSO */ -- 2.53.0.rc1.225.gd81095ad13-goog