Re: [PATCH 3/3] hwmon: (sht4x) Fix jiffies wraparound in heater-ready check

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] hwmon: (sht4x): torn read of heating_complete in heater_enable_show()
--

commit 90157fd25e4d294f6299c304227e07d23632d8e9
Author: Tom Verdonck <tom.verdonck@inspiral.be>

hwmon: (sht4x) Fix jiffies wraparound in heater-ready check

This commit changes the heating_complete field to a 64-bit jiffies
value to prevent wraparound issues after ~248.5 days on 32-bit systems.
It updates usages of this field to use get_jiffies_64() and
time_before64().

> diff --git a/drivers/hwmon/sht4x.c b/drivers/hwmon/sht4x.c
> index a97dda9e92dc5..da2b6130fca7e 100644
> --- a/drivers/hwmon/sht4x.c
> +++ b/drivers/hwmon/sht4x.c
[ ... ]
> @@ -237,7 +237,7 @@ static ssize_t heater_enable_show(struct device *dev,
>  {
>  	struct sht4x_data *data = dev_get_drvdata(dev);
>  
> -	return sysfs_emit(buf, "%u\n", time_before(jiffies, data->heating_complete));
> +	return sysfs_emit(buf, "%u\n", time_before64(get_jiffies_64(), data->heating_complete));
[Severity: Medium]
Since heating_complete is now a 64-bit field, does this read in
heater_enable_show() need to be protected by hwmon_lock?

If a user-space read to the heater_enable sysfs attribute runs concurrently
with a write via heater_enable_store(), it would race with the update to
data->heating_complete which is done under the lock.

Could this result in a torn read of data->heating_complete on 32-bit
architectures, causing an incorrect boolean value to be emitted?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1790358356.git.tom.verdonck@inspiral.be?part=3