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
