Re: [PATCH net-next v2 3/6] eth: fbnic: cache hwmon sensor readings

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Using `time_is_after_eq_jiffies()` with a past timestamp causes up to 24.8 days of stale cache hits due to integer wrap-around.
--

commit 7ed3f7f9496f73d45331fe15e8dabb135858cab0
Author: Zinc Lim <limzhineng2@gmail.com>

eth: fbnic: cache hwmon sensor readings

This commit caches hwmon sensor readings for the remainder of the current
jiffy to avoid flooding the firmware mailbox with quick, successive IPC
messages when polling attributes at a high rate.

> diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c b/drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c
> --- a/drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c
> +++ b/drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c
[ ... ]
>  static int fbnic_hwmon_sensor_read(struct fbnic_dev *fbd, int id, long *val)
>  {
[ ... ]
> +
> +	if (*cached != FBNIC_SENSOR_NO_DATA &&
> +	    time_is_after_eq_jiffies(cache->last_read)) {
> +		*val = *cached;
> +		return 0;
>  	}

[Severity: Medium]
Does this cache validity check safely handle long periods of inactivity?

Using time_is_after_eq_jiffies() with a past timestamp can cause up to 24.8
days of stale cache hits due to integer wrap-around.

On 32-bit architectures, if the sensor is not read for more than 24.8 days
(assuming HZ=1000), the difference between the current jiffies and
cache->last_read wraps around the 32-bit signed boundary and becomes positive.

When this happens, the time_is_after_eq_jiffies() macro in
fbnic_hwmon_sensor_read() evaluates to true, causing the driver to serve
completely stale temperature and voltage data for the next 24.8 days instead
of properly refreshing the hardware state.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831212234.1212971-1-limzhineng2@gmail.com?part=3