-----Original Message-----
From: Karas, Krzysztof <[email protected]> 
Sent: Tuesday, February 24, 2026 8:19 AM
To: Cavitt, Jonathan <[email protected]>
Cc: [email protected]; Gupta, Saurabhg 
<[email protected]>; Zuo, Alex <[email protected]>; 
[email protected]
Subject: Re: [PATCH] drm/i915/gem: Explicitly return error value from 
eb_relocate helpers
> 
> Hi Jonathan,
> 
> On 2026-02-04 at 23:03:08 +0000, Jonathan Cavitt wrote:
> > Static analysis issue:
> > 
> > The current implementations of the eb_relocate_vma and
> > eb_relocate_vma_slow functions cast the return value of
> > eb_relocate_entry to a signed long in order to determine if an error has
> > occurred.  This is because the return value of eb_relocate_entry is a
> > u64 offset value on a success and a negative error value on a failure.
> > 
> > While not mechanically incorrect,
> This might lower the perceived need for this change, just leave
> that it is improper to cast stuff like this and that should be good.

Will do.

> 
> > it is improper to perform a cast like
> > this.  So, just have eb_relocate_entry (and, by extension, its helper
> > function relocate_entry) return the error value, storing the offset
> > separately in a passed u64 pointer.
> > 
> > Interestingly, this value is only used for non-error-checking purposes
> > in the eb_relocate_vma case.  We can simplify the eb_relocate_vma_slow
> > case by allowing the passed u64 pointer to be NULL because of this.
> > 
> > Signed-off-by: Jonathan Cavitt <[email protected]>
> > Cc: Joonas Lahtinen <[email protected]>
> > ---
> 
> I think the code looks good, but you should address failures
> from i915 CI - both test runs on this patch look more or less
> the same, so this change might be breaking something.

Found it: offset and error values were no longer correlated, so when an error 
would
occur in eb_relocate_vma, it would be ignored due to offset == 0 hitting first.
Reordering the two cases should repair the issue.  Will submit an update 
shortly.
-Jonathan Cavitt

> 
> -- 
> Best Regards,
> Krzysztof
> 

Reply via email to