Re: [PATCH 2/6] drm: Add drm_timeout_rel_to_jiffies()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The overflow guard in `drm_timeout_rel_to_jiffies()` is ineffective on 64-bit architectures, failing to prevent internal `u64` wrap-around in `nsecs_to_jiffies64()` for specific inputs.
--

--- Patch [2]: [PATCH 2/6] drm: Add drm_timeout_rel_to_jiffies() ---
commit c015d0990b1688d1fc81fe1000d64e7430d1d234
Author: Maíra Canal <mcanal@igalia.com>

drm: Add drm_timeout_rel_to_jiffies()

This commit introduces drm_timeout_rel_to_jiffies() to convert relative 
nanosecond timeouts into jiffies. It is intended for drivers whose wait UAPI 
takes a duration instead of an absolute deadline, and includes an overflow 
check to safely handle large values.

> diff --git a/drivers/gpu/drm/drm_timeout.c b/drivers/gpu/drm/drm_timeout.c
> index 78e9f65e54779..30ad3e8ebc92a 100644
> --- a/drivers/gpu/drm/drm_timeout.c
> +++ b/drivers/gpu/drm/drm_timeout.c
[ ... ]
> @@ -45,3 +46,31 @@ signed long drm_timeout_abs_to_jiffies(int64_t timeout_nsec)
>  	return timeout_jiffies64 + 1;
>  }
>  EXPORT_SYMBOL(drm_timeout_abs_to_jiffies);
> +
> +/**
> + * drm_timeout_rel_to_jiffies - calculate jiffies timeout from relative value
[ ... ]
> +unsigned long drm_timeout_rel_to_jiffies(u64 timeout_nsec)
> +{
> +	/* make 0 timeout means poll, as for the absolute variant */
> +	if (timeout_nsec == 0)
> +		return 0;
> +
> +	/* nsecs_to_jiffies64() does not guard against overflow */
> +	if ((NSEC_PER_SEC % HZ) != 0 &&
> +	    div_u64(timeout_nsec, NSEC_PER_SEC) >= MAX_JIFFY_OFFSET / HZ)
> +		return MAX_JIFFY_OFFSET;

[Severity: Medium]
Is this overflow guard effective on 64-bit architectures?

On 64-bit systems, MAX_JIFFY_OFFSET is around ~4.6e18, so MAX_JIFFY_OFFSET / HZ
is roughly ~4.6e16. Since timeout_nsec is a u64, div_u64(timeout_nsec, NSEC_PER_SEC)
can never exceed ~1.8e10, meaning this condition is mathematically impossible to
trigger on 64-bit platforms.

Because the guard can never be met, can highly specific inputs cause
nsecs_to_jiffies64() to silently wrap around internally?

For example, when HZ makes nsecs_to_jiffies64() use the n * 9 calculation, a
carefully chosen timeout_nsec (like ~64.9 years, or around 2049638230412172402
ns) could wrap around internally to a near-zero jiffies value, resulting in a
premature timeout.

> +
> +	return min_t(u64, MAX_JIFFY_OFFSET, nsecs_to_jiffies64(timeout_nsec) + 1);
> +}
> +EXPORT_SYMBOL(drm_timeout_rel_to_jiffies);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260809-drm-timeout-helpers-v1-0-2de67405a145@igalia.com?part=2