From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) (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 C0AAC23EA93 for ; Mon, 16 Feb 2026 11:09:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771240160; cv=none; b=amRF4sJTMOjbsQs3RrUSJ5zYiGuohx8X6YwIW/40rgvJDV2W4o6aa/NgdCdrZ6SXvFEMC3YZt/m/nVhPmu4aFfm/Sf/YFQHnFRQiy+gVDlmqnZVJSU394MtI3HDHxfioMkx8ey5t3wvO928ohbCEd9IjWDIgYrfQUrMQK3qIUbY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771240160; c=relaxed/simple; bh=yL10Snrz9gC6XYMsJoWK+o5r2O/79dphE2aaEfhCQ9w=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=H0YezxgrJBBBVb1Mn57XPG1CqkeMkBEaD9yE79mRPBhoPnwDWAW/uLUeFBs6ZvUXmdE524vpaXr2fUmmzI1IwrztbIlxMw/68LNqtw/KsPjnKgrNOZfjgnlvaLX0g2/ME7nzdtznZ8M86nlr0L05+JmycczuYwEbMLB+CVnO+xI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=nq9Q/HIb; arc=none smtp.client-ip=209.85.221.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nq9Q/HIb" Received: by mail-wr1-f65.google.com with SMTP id ffacd0b85a97d-436263e31abso2939552f8f.1 for ; Mon, 16 Feb 2026 03:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771240157; x=1771844957; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=86+3Ol8ufgkpxEsjqivLYye2L+eLEE02N4njJxkXOz4=; b=nq9Q/HIbzsnIDylToYHDZAszNv12a/Cn+nJtV9qyPgOoohVyhzWLoXU/AN/us+qVmQ iy5y90vX0xTceN54xGIpRlz8cO0RQMmVALhsHpAQagzXvnfcLWruhaEqGZ/OFmncyCJj 7sA808Eut2tGbuxTGYnp4QHpBeMeVuCgTG3/CA0Lt/WoX4LDa9ZLvkYpDiOmix5BHX+v Zofd6eNUOxuLzzIDaBS63jIcYRwVy86qG9xZIfr8rSnmb+4Jhb9MFG4qBnBY+x1dNQ9v Vb8vwXpdPPAD3NMzqSjkq5gKVpN6huGCwzniml7kelt0FHaQubY2hmS7r8rUmrGRTcxL gsNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771240157; x=1771844957; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=86+3Ol8ufgkpxEsjqivLYye2L+eLEE02N4njJxkXOz4=; b=N/YQOtIhvHKuHvMs+aSc4pwOx6eaNeCBj95LvC6/94o1FmvjWu5BJqNMcm5F4lEYAy wOp+XBz9IjkUd55mbcwy20taWXlZVRL0SAeH9vO60L7CCqADAP2wR4d+lFEUuGcacCHu b9ES+j9LufzfAO7pIsJu/aEsArrYw3LEEpWT2HmbMJmoNaaZAsgy8OkqOm0j4FIora3O aZQmjIzHuU/HsRjqqXHInjlT1IatEOfscPHklILcHav9kRvV4fpmS5/hlKxDUuW24RK5 NETgDJz0U2OZdwJdrwnsIFIf/duXpX2y3osoplVUfucT6IyyyynpWW9hDY5o348gpPAM nCzQ== X-Forwarded-Encrypted: i=1; AJvYcCUvBgXLdMGMVp3in3Zv7B68pu+TJ1wtdwltzQ8qJa/8ElmCWB2MmgHF1WYO/ie1u+r3T8lz388btUwOOOE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx6nMACtQjH3UQhO3ETGxVpH8ADlBagoVvCgerY6Ojbozkg652n lsYl4OM8pVilWrk5GvxC7d92KtN0r8INMvaA9kzKrQKH4HLS0TKlkQKu X-Gm-Gg: AZuq6aKwNOZoK29TDXIIklHqta4XZF4PGmYEr7IE4bJfJfR2Hfv7HQUMeiu51Rslg+6 a7KMXFYLviOJmWxAIuGSVztzdDE06UxRDNyf7A9HegvdC7trQSP5jL9BRc63O9lEZPTQJX0mhMw m/BvD6WRBwZDPIFrnP8iTrL8hh6XvqRTCZu6cGQKilBakojk/kzS4s3trSA+GwxDCaYd+jEQjBG te0riFpJjySvcfa339efOKl6nUSg5Mnh0f+p0Gwul1lLCbRfrds9acLR/rdDQi/EnrRICbjpHlu h1uoa6iKGw3ci4asrcRIRXzP/o0/4MOrS0j6H8Ytmx9ijUhvbMylGvthPLEOSi5tzCcGho/xBYY oKyf2lxGLJeyobd74Zh59/99If76LiLw0jSBDw+2OJ81/XDO41Ns2YsPXId0uBPFsP/IzI7uR/U 2YGRt6rTBMIX1qAZdQ1ZMPvGY7muCUmTLNB9bopwHSxt+rb4HPXlX6a7tL6XzUiH/+ X-Received: by 2002:a05:600c:3e87:b0:480:32da:f338 with SMTP id 5b1f17b1804b1-48373a0f961mr151759405e9.14.1771240156943; Mon, 16 Feb 2026 03:09:16 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4835dcfafcdsm657254105e9.9.2026.02.16.03.09.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 03:09:16 -0800 (PST) Date: Mon, 16 Feb 2026 11:09:15 +0000 From: David Laight To: Linus Torvalds Cc: Marco Elver , Will Deacon , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Boqun Feng , Waiman Long , Bart Van Assche , llvm@lists.linux.dev, Catalin Marinas , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel test robot , Boqun Feng , Al Viro Subject: Re: [PATCH v3 3/3] arm64, compiler-context-analysis: Permit alias analysis through __READ_ONCE() with CONFIG_LTO=y Message-ID: <20260216110915.4f0d5490@pumpkin> In-Reply-To: References: <20260130132951.2714396-1-elver@google.com> <20260130132951.2714396-4-elver@google.com> <20260202192923.0707e463@pumpkin> <20260204131400.GI2995752@noisy.programming.kicks-ass.net> <20260206182650.6c21b0ff@pumpkin> <20260215221656.68b2fc1d@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: 7bit On Sun, 15 Feb 2026 15:40:07 -0800 Linus Torvalds wrote: > On Sun, 15 Feb 2026 at 14:44, Marco Elver wrote: > > > > I found e.g. xen_get_runstate_snapshot_cpu_delta() uses the >8 byte > > case via __READ_ONCE(). READ_ONCE() itself is already restricted to <= > > 8 bytes (due to that static assert), but that itself uses the > > __READ_ONCE() helper which these patches were touching. > > I think we could just make __READ_ONCE() be totally unchecked - just > make it be "const volatile typeof()" and leave it at that. > > Anybody who uses __READ_ONCE() would then have to deal with it. > > There are very few users of that left, I think it's mainly > arch_atomic_read(), which just doesn't want any of the checking that a > regular "READ_ONCE()" does. > > In fact, there are *so* few users left that I think we could probably > just remove __READ_ONCE() entirely, and make our "atomic_t" use > "volatile" in the type itself. > > I generally absolutely hate volatile on data structures - it's a > design mistake (an understandable one: it was at least partly designed > for memory mapped IO accesses), and the volatile should be in the > accesses, not the data, because very often the volatility of the data > depends on context, not on the data. IIRC The bots are now bleating when there is a READ_ONCE() in one place but a write without a matching WRITE_ONCE(). That is effectively forcing all the accesses to be volatile regardless of the context. Which is pretty much equivalent to making the structure members volatile. So if all you care about is 'inverted CSE' and read/write tearing then volatile structure members DTRT. What you probably don't want is 'volatile struct foo *'. volatile structure members are almost free, you lose CSE and some versions of gcc 'forget' that a load zero/sign extended a byte and do it again. (I had to use barrier() rather than volatile in some code where I really did care about single instructions.) I've never see gcc reload a local, but I have seen it do CSE then spill the value to stack. David > > But our "atomic_t" is already properly wrapped, and nobody should be > accessing it with anything but our helpers, so putting the volatile > there looks ok. > > Linus >