From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 E78DD33B6F8 for ; Mon, 9 Feb 2026 09:50:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770630642; cv=none; b=Gqg56r+saltHABIrOUDCAdL9zvIlhqclgzG803xoF7+mK3mO+yTIUld0ztcyfEw3kAUW54Wunxqzf1sI9mnQtcVtfQ56h4zR7oYcm6/GyIweavQEnob8d1okqCARp/Xfv+03moSbC2i6xN+ucTQlxc+ZOIftpqqbQ6/b9tbAlHY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770630642; c=relaxed/simple; bh=G0AZtPKM9LqmL8+9X5WtJjbdlbwoTFZvZ9q6vhURmcc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Rw3H1noVelxAICLMLxQRGZXm80L66hHKw3lcFlOFONEw7oOw6xjQToo1JjtlmmdtBUOuMzg5VWT3HInRE6480HvqIZTm/NLg9II6KuhrIC41bQcL6mX55IshFf6XGc+be2bgkibAKq8oER87GYAXX9o2/Pd6EHwC010baBDoN3U= 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=QkrESqaO; arc=none smtp.client-ip=209.85.221.51 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="QkrESqaO" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-43770c94dfaso690863f8f.2 for ; Mon, 09 Feb 2026 01:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770630640; x=1771235440; 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=G3Fl1LdKzLTKTPiN1YZNuSPUICwP+bYYrhH9RATSKdE=; b=QkrESqaOo2uIYUQEwMF7O1u4QzRqqiSn5/5X1VnxFmhyw6qP93+e8lmjeeyi/sZE8v xZEsSmrlfYXCoFP23EPEsXR61m8kLjdqDpF84S9JU8mKOGh48aPJtvAn/Bdh77n5YdIS 59ZuwsOEcWaHAXyan48s10JC3O4nWZrs6i6+r/9g/12gllOIenR/Y49A8k4h8lYJ90Aa Ou37v4UpM5s6zXTxlANh5ZbyFyt6Hr/n9d4+Z1XUQJcIo8hDhXWn8cceuxy98wXJKHhT wysYEsCeOpF6InYOYS4x9c95sXciZCVCnoiv3j6kcav5TrL954V+5Ud4flW6RNMCmyTu eQYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770630640; x=1771235440; 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=G3Fl1LdKzLTKTPiN1YZNuSPUICwP+bYYrhH9RATSKdE=; b=fOhBqevTVVpWjcDsOmsYPFq/lITvxVxHJwgF3vPxn2SxSO38Dnp8Up0ormGd+A0cmP wUKN6Fwo+IcWM53arHto2bE/G5pLs2kkNc7DQ0X/w6/ZeO0hmGMgex/1hdsj0fQjKowk hUDYPMQdsagA7wSGFYm//Ld52swAnUADmPbeoeEygW+gWkWuiu6ZZUQP3QGm54+VCLmB p6UZSFTK1Lyxl4mVlhnisB8pc6f65ZYDaM1Qn7IoNfWCv16wM+ucAIjmawlpdXsdRZlE vsSi9nFtGUJjZnpuQUWZ0INgEGJT7CTW9lW04RTtNMPlTwy0Y7e3TZyjQX3w0yU1erJh WcAQ== X-Forwarded-Encrypted: i=1; AJvYcCXvHm64xLoO+sCTvG0q+FSSS07TCn2YNnavpjXaZSiD+qUntXBKc+CEYY6OBTnJwiLq6AMNAgqlfpqNl3c=@vger.kernel.org X-Gm-Message-State: AOJu0Yw//LoEHcgPEMtjf/b+x4yfyY8YA7Bd4/vlyt3z3leHAnwziDYx dzgoeqF6J8TO5ve0UW9X2T7JiDGsVOClf21BNUIulbMPEgfb6NP/nYii X-Gm-Gg: AZuq6aIB40shpg787fc5Rz13fKauw1cZ4FIPESaNCoDWUcF3QSQQvnb+HwpUiycMZuT b5WeCPDyNRA0gLOe8/u1rV1jaf9GZZaX+jbRYsRu2iVRQVUB1u5/+btJMd78eufNWqTA9USnPVL R6eO52OVNoTlKkYIljlnzQNivgZKkksLSZ6xy5jUpesDTGk/8C/pT8U6M2XJ2YR8PniiRxBFZcD EYEhJhu3LSSZALZ8x/nlaEWKIJPxIt4FTmxybmJU1AIEzNIzQJWqx5G1KQkdT4IF5kBKmIpb65h v43PoMI9e95hLSQLPlpFL73SDRXFmwW7ZabXUUCZMwYVGU1u0jlvkLPe0HWzFCH7+e8Ho2RPfVK Jw0OFg+LzjwW6RN6K2qbGCuODYsJCStZW/ffk0iGQDBZ882qnU8Hu1yAmWtuWMJLt6C3uwTc6HM nwqyJzTJuA+0lbngrj2gD70Gj5Tnxsgwqxz45Zx0g0b2my8YuSe+kw X-Received: by 2002:a05:6000:3105:b0:436:42cc:25ec with SMTP id ffacd0b85a97d-43642cc27d7mr6508644f8f.9.1770630640051; Mon, 09 Feb 2026 01:50:40 -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 ffacd0b85a97d-437699bc1cdsm11376577f8f.7.2026.02.09.01.50.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Feb 2026 01:50:39 -0800 (PST) Date: Mon, 9 Feb 2026 09:50:38 +0000 From: David Laight To: Ben Hutchings Cc: Gui-Dong Han , linux@roeck-us.net, linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, stable@vger.kernel.org Subject: Re: [PATCH] hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization induced race Message-ID: <20260209095038.50e62eda@pumpkin> In-Reply-To: <000915fc444a6e1f840f3d4ed6493058aefe850f.camel@decadent.org.uk> References: <20260203121443.5482-1-hanguidong02@gmail.com> <20260207104308.1bc31102@pumpkin> <20260208114810.3709364b@pumpkin> <000915fc444a6e1f840f3d4ed6493058aefe850f.camel@decadent.org.uk> 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, 08 Feb 2026 23:33:31 +0100 Ben Hutchings wrote: > On Sun, 2026-02-08 at 11:48 +0000, David Laight wrote: > > On Sat, 07 Feb 2026 12:43:29 +0100 > > Ben Hutchings wrote: > > > > > On Sat, 2026-02-07 at 10:43 +0000, David Laight wrote: > > > > On Tue, 3 Feb 2026 20:14:43 +0800 > > > > Gui-Dong Han wrote: > > > > > > > > > Simply copying shared data to a local variable cannot prevent data > > > > > races. The compiler is allowed to optimize away the local copy and > > > > > re-read the shared memory, causing a Time-of-Check Time-of-Use (TOCTOU) > > > > > issue if the data changes between the check and the usage. > > > > > > > > While the compiler is allowed to do this, is there any indication > > > > that either gcc or clang have ever done it? > > > > ISTR someone saying that they never did - although I thought that > > > > was the original justification for adding ACCESS_ONCE(). > > > > > > They do it sometimes and it's precisely why these maros were added. It > > > makes no sense to me to look at what these compilers currrently do (for > > > some particular versions, optimisation settings, and targets) and > > > extrapolate that to the assertion that they will never optimise away a > > > copy. > > > > > > > READ_ONCE() also includes barriers to guarantee ordering between cpu. > > > > These are empty on x86 but add code to architectures where the cpu > > > > can (IIRC) re-order writes. > > > > This is worst on alpha but affects arm and probably ppc. > > > > > > No, READ_ONCE() and WRITE_ONCE() don't include any CPU memory barriers. > > > > Look at the alpha version and the arm64 LTO code. > > The latter changes the reads to have 'acquire' semantics to stop re-ordering. > > Needed for LTO, but the thought is it might be needed in other cases. > [...] > > Oh, so they do. Sorry for "correcting" you based on my old information. I'm not at all sure that the field which just need protection from TOCTOU and load/store tearing shouldn't just be marked volatile. ISTR that part of the original objection was that not all accesses needed it - but the static check code seems to be enforcing that now. Marking things volatile mostly stops the compiler doing CSE - which is exactly what you want here. David > > Ben. >