From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 9B041242D76 for ; Sat, 7 Feb 2026 05:31:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770442263; cv=none; b=ax8Ye6NE0Zoe53oIsrKoqy3/SMNeU1Sa28l/jy1twXcwMwFhnkd4yYnoqKY2BukMCaWiQPHrEdO7rZb8lu48ijXG9+eZRRkFiLeSc5aht1/hC/rnoNHTr5YXeM0fFmWM+0WCqFM2kf/kaXAqi3pihuT8GLQiOdDWVkxOm9vqTNk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770442263; c=relaxed/simple; bh=6CMcImivz+9TGRX6cDLBO8eka/508xuj+j3Oja7JGm0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hX9bL1zJEA+UvGkAub/6ykzHOeL1ci/IiFj1qND3wCjk+JBgRqu6QqkncwEmisbPBQVsjh3JQiwMiYFUILOHF6oZPWFecvQ708ho08CXsBeMQepMUxfMG9b5z9ZMd0zfgkhNB7fQL7og0v/yAuX82ibdp6kj0AkSri7ciQeTXhg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WbeFA12x; arc=none smtp.client-ip=209.85.214.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net 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="WbeFA12x" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2a7b23dd036so6610925ad.3 for ; Fri, 06 Feb 2026 21:31:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770442263; x=1771047063; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=4r1/bFgz7fHK5C32YZ4rSXfMrTJXSkBGVxxwZofFjNE=; b=WbeFA12xzJuk376PJZiXUbBxj3q4SsX5K4+QwxVDAomx05MQgsnby172h91hcuUfLV NVvVky9zL+ugNcK2x+F3+7NTEsbymg5bRLirF18gCuscXZusUCNRAbrGv0ICVhPxBuza wYql06qaBmonB735k4QT8N3BBSPsL7t9iIB2t856K+ckoA0Ir5cYTx7P09NaCcgMH28k EOmIf5wbFcreXagevUeTrypxW1v7a2b/HGPDhnwWsQBvAx5d9d7n/1SRWbrbM8bAn3Gg Lek7CT7Sxq5Wl47rVVfvpxwu/vdkXlG0MpQ5sDBTiURB6p4QsCj0WVLPaGH78EWVDsd5 ZwkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770442263; x=1771047063; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=4r1/bFgz7fHK5C32YZ4rSXfMrTJXSkBGVxxwZofFjNE=; b=MDE+JtkPhE39ntTx2JYTKQn5i1a/GWgdCNbfV7yun59iZh90bARVQxVhbGp+ohFRBh Zimi9fGgtu0npKtFqhtXZtXyhrbDzL4Vi8vOLMSAhGz0Y2wfPIGpO6mqpVL9ehzg1X5S aXNfqI2USjJqhxr3PzRRxt5bShkTdAVvxSGf22nFFPzWXlQJx1kKJjcESgMj9vX8Qpib nXYON/BsZGz/TXP5a95CLkojmuQJ+wyNBre+/ukKp2U0NIyYSFy2XWse54Jb/9ifbaZA 1ieDeJHqRHyR88dzpxq7NfjRocW69KMQpmSJMxKCdop5zlrwvRE/eLJ/qE43++47Mnnv 3cVg== X-Forwarded-Encrypted: i=1; AJvYcCXwsvTULmOA9NF/sPGEfh1S8lNdPzNsCSKwFzipVRJW0NuFsBogAvJGw3HljErz/wIV7/4Fvfm0M4IkcV0=@vger.kernel.org X-Gm-Message-State: AOJu0Yxmybax4BVO0Fii1T8jR7uzJHLVQ/sceSr2hsluQeKsjdiw66kD Vfkmtmy0iN+84zM3tX59U1z7yPxtFvoumoIGZKufza985cQOv6TY+VcY X-Gm-Gg: AZuq6aLGHRSDDa88C6SuQSXHApjPJkD8ST6DRi8U+AoQAzmr2dXejNx1SkSfnu8iiRN qGKF9fQ/bB2x0sLfDS1atVzGAnRDtyrWvQPdTiE3SkGQRKA5IgDuKm0OrFDy5MVd/CInW3Dqw+4 1x5eoGqng19OZ4TiRJ+xHrvEUxYgb9B1c+iziqnDywu7IaLkpM+VRaKi4Mq6bcezwNBx0Hm3QeC uULoBBW+cqKFB5e9JMvbde52TqeSDJKngd3u3qP/yZD9D8Lz1hNk1FvVKsQfFEhlOA026miLRqV aAGj4+mG1tsux29Q+/9qQtM785JTwpMKNY5CZ2X4GJA9Nq5pNeKal6dxNL4CmwnZUHtKBQKphfb nwTlzrV1JTDzrwliSn1hs3f0x/Uv5nBMF2MG7s3gnnGsdo67r8woFaPM8v0nY/ZprsiXUUCfOp+ s+nhFouZoXifvYwvJFWpb4vFKBu/rS3EHLvF2U X-Received: by 2002:a17:902:cf07:b0:295:5dbe:f629 with SMTP id d9443c01a7336-2a951608c6bmr47072025ad.8.1770442262725; Fri, 06 Feb 2026 21:31:02 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:da43:aeff:fecc:bfd5]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a96251b6edsm10731145ad.69.2026.02.06.21.31.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Feb 2026 21:31:02 -0800 (PST) Sender: Guenter Roeck Date: Fri, 6 Feb 2026 21:31:00 -0800 From: Guenter Roeck To: Gui-Dong Han Cc: linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, Ben Hutchings , stable@vger.kernel.org Subject: Re: [PATCH] hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization induced race Message-ID: <3d81c0ff-bd80-4b06-9a59-545b5d94e6a4@roeck-us.net> References: <20260203121443.5482-1-hanguidong02@gmail.com> 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: <20260203121443.5482-1-hanguidong02@gmail.com> On Tue, Feb 03, 2026 at 08:14:43PM +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. > > To enforce the use of the local variable, use READ_ONCE() when reading > the shared data and WRITE_ONCE() when updating it. Apply these macros to > the three identified locations (curr_sense, adc, and fault) where local > variables are used for error validation, ensuring the value remains > consistent. > > Reported-by: Ben Hutchings > Closes: https://lore.kernel.org/all/6fe17868327207e8b850cf9f88b7dc58b2021f73.camel@decadent.org.uk/ > Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles") > Fixes: b8d5acdcf525 ("hwmon: (max16065) Use local variable to avoid TOCTOU") > Cc: stable@vger.kernel.org > Signed-off-by: Gui-Dong Han I don't claim to be an expert in this area, so I ran the patch through an AI review and asked it if it is both necessary and complete. It claims that this is the case, so I am going to apply this patch. For those interested, I attached the AI review results below. Thanks, Guenter --- [AI generated] Summary: The patch addresses a theoretical data race and TOCTOU (Time-of-Check Time-of-Use) issue where compiler optimizations could reload shared data (data->adc, data->curr_sense, data->fault) after a validity check but before usage. By employing READ_ONCE in the reader functions (max16065_alarm_show, max16065_input_show, max16065_current_show) and WRITE_ONCE in the updater (max16065_update_device), the change ensures that the compiler treats these accesses as volatile, preventing reloads and ensuring that the value checked is the same as the value used. The logic correctly handles the "lockless reader / locked updater" pattern common in hwmon drivers. Verification: * Concurrency: The max16065_update_device function holds data->update_lock during updates, ensuring only one thread updates the cache. The READ_ONCE/WRITE_ONCE macros correctly protect against compiler tearing/reordering for the readers that run outside this lock. * Error Handling: Error codes from i2c_smbus_read_byte_data and max16065_read_adc are correctly stored in the data structure and checked in the show functions (via unlikely(val < 0)). * Code Style: The changes follow kernel coding style and best practices for concurrency annotations. * Regressions: No regressions were found. False Positives Eliminated: * Self-read in `max16065_update_device`: The line WRITE_ONCE(data->fault[0], data->fault[0] | data->fault[1]); reads data->fault[0] without READ_ONCE. This is safe because max16065_update_device holds the update_lock, so no other thread can be modifying data->fault concurrently.