All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Verdonck <tom.verdonck@inspiral.be>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
	Tom Verdonck <tom.verdonck@inspiral.be>
Subject: [PATCH 0/3] hwmon: fix jiffies wraparound in one-shot ready checks
Date: Fri, 25 Sep 2026 20:23:21 +0200	[thread overview]
Message-ID: <cover.1790358356.git.tom.verdonck@inspiral.be> (raw)

Several hwmon drivers store a one-shot jiffies deadline that is set once
and never refreshed, then compare it against the current time with
time_before() on every access. time_before() only interprets the signed
difference of two jiffies values correctly while they are within
LONG_MAX jiffies of each other. Because the deadline is frozen while
jiffies keeps advancing, the difference eventually flips sign: after
2^31 jiffies (~248.5 days of uptime on a 32-bit HZ=100 kernel) the check
inverts and stays wrong for the next ~248.5 days.

The consequences differ per driver:

  - tmp102, tmp108: every temperature read then returns -EAGAIN without
    ever touching the sensor, until the machine is rebooted. This has
    been observed in the field on 32-bit systems that had been up for
    ~248 days.
  - sht4x: the read path instead concludes the heater is still active
    and calls msleep() with a bogus, huge delta, blocking the read for a
    very long time.

Each is fixed the same minimal way: store the deadline in a u64 jiffies
value and compare it with get_jiffies_64()/time_before64(), which does
not wrap in any realistic uptime. No functional change on the hot path
other than removing the false-positive after the wrap point.

The other hwmon time_before(jiffies, ...) users I looked at are not
affected: they either re-stamp last_updated on every update (the usual
cache pattern, e.g. tmp421, tmp464, tc654, g762, ibmpex, w83792d) or use
a freshly computed local timeout (pmbus/ltc2978), so their two operands
never drift apart.

The failure itself takes ~248 days of uptime to reproduce and follows
directly from the time_before() semantics; it was traced from a field
report of a 32-bit board stuck returning -EAGAIN after ~248 days.

Build-tested on x86-64 and cross-compiled for 32-bit ARM (Cortex-A7,
arm-linux-gnueabi) with make W=1; all three objects build cleanly with
no new warnings. 32-bit ARM is the configuration in which the bug
actually manifests.

Tom Verdonck (3):
  hwmon: (tmp102) Fix jiffies wraparound in conversion-ready check
  hwmon: (tmp108) Fix jiffies wraparound in conversion-ready check
  hwmon: (sht4x) Fix jiffies wraparound in heater-ready check

 drivers/hwmon/sht4x.c  | 18 +++++++++---------
 drivers/hwmon/tmp102.c |  8 ++++----
 drivers/hwmon/tmp108.c |  8 ++++----
 3 files changed, 17 insertions(+), 17 deletions(-)

-- 
2.53.0


             reply	other threads:[~2026-09-25 18:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25 18:23 Tom Verdonck [this message]
2026-09-25 18:23 ` [PATCH 1/3] hwmon: (tmp102) Fix jiffies wraparound in conversion-ready check Tom Verdonck
2026-09-25 18:29   ` sashiko-bot
2026-09-26  3:25   ` Guenter Roeck
2026-09-25 18:23 ` [PATCH 2/3] hwmon: (tmp108) " Tom Verdonck
2026-09-25 18:30   ` sashiko-bot
2026-09-26  3:26   ` Guenter Roeck
2026-09-25 18:23 ` [PATCH 3/3] hwmon: (sht4x) Fix jiffies wraparound in heater-ready check Tom Verdonck
2026-09-25 18:33   ` sashiko-bot
2026-09-26  3:27   ` Guenter Roeck
2026-09-28  6:22   ` [PATCH] hwmon: (sht4x) Fix torn read of heating_complete in heater_enable_show() Tom Verdonck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1790358356.git.tom.verdonck@inspiral.be \
    --to=tom.verdonck@inspiral.be \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.