Re: [PATCH v2 6/6] drm/vc4: Use drm_timeout_rel_to_jiffies()

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete Fix / Unhandled 32-bit Overflow in `vc4_wait_for_seqno`
--

--- Patch [6]: [PATCH v2 6/6] drm/vc4: Use drm_timeout_rel_to_jiffies() ---
commit 4c26550a287cbb245dc4be4698ea36a63eca121d
Author: Maíra Canal <[email protected]>

drm/vc4: Use drm_timeout_rel_to_jiffies()

This patch updates vc4_wait_bo_ioctl() to use drm_timeout_rel_to_jiffies()
instead of usecs_to_jiffies(). This prevents long timeout values from
wrapping around into much shorter timeouts due to unsigned int narrowing.

> diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
> index e231c906709c1..781aeb8967b15 100644
> --- a/drivers/gpu/drm/vc4/vc4_gem.c
> +++ b/drivers/gpu/drm/vc4/vc4_gem.c
> @@ -970,7 +971,7 @@ vc4_wait_bo_ioctl(struct drm_device *dev, void *data,
>  	int ret;
>  	struct drm_vc4_wait_bo *args = data;
>  	unsigned long timeout_jiffies =
> -		usecs_to_jiffies(div_u64(args->timeout_ns, 1000));
> +		drm_timeout_rel_to_jiffies(args->timeout_ns);

[Severity: High]
This isn't a bug introduced by this patch, but I noticed that
vc4_wait_for_seqno() also appears to need a similar fix.

Could this lead to immediate early expiration on 32-bit systems for large
timeout values?

It calculates timeout_expire using nsecs_to_jiffies() without clamping to
MAX_JIFFY_OFFSET:

drivers/gpu/drm/vc4/vc4_gem.c:vc4_wait_for_seqno() {
    ...
	if (timeout_ns == 0)
		return -ETIME;

	timeout_expire = jiffies + nsecs_to_jiffies(timeout_ns);
    ...
}

If the resulting jiffies offset exceeds MAX_JIFFY_OFFSET, adding it to jiffies
would result in a value that time_after_eq() evaluates as being in the past,
causing the wait loop to exit immediately with -ETIME.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=6