Re: [PATCH v4 26/32] drm/xe/pcode: Report 'timeout, retrying' error using SIGID

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

Pre-existing issues:
- [High] Uncapped exponential backoff causes udelay() to exceed architecture limits, risking integer overflow and undefined delay times.
--

--- Patch [26]: [PATCH v4 26/32] drm/xe/pcode: Report 'timeout, retrying' error using SIGID ---
commit 75f6f9c4d8c1d251fab2b4d894d2352070119c43
Author: Michal Wajdeczko <[email protected]>

drm/xe/pcode: Report 'timeout, retrying' error using SIGID

This commit replaces a drm_err message with the xe_log_err helper to report 
PCODE timeout retries using the SIGID tagging infrastructure.

> diff --git a/drivers/gpu/drm/xe/xe_pcode.c b/drivers/gpu/drm/xe/xe_pcode.c
> index 014632e113388..14b13a11d1d6d 100644
> --- a/drivers/gpu/drm/xe/xe_pcode.c
> +++ b/drivers/gpu/drm/xe/xe_pcode.c
[ ... ]
> @@ -218,8 +218,7 @@ int xe_pcode_request(struct xe_tile *tile, u32 mbox, u32 request,
>  	 * requests, and for any quirks of the PCODE firmware that delays
>  	 * the request completion.
>  	 */
> -	drm_err(&tile_to_xe(tile)->drm,
> -		"PCODE timeout, retrying with preemption disabled\n");
> +	xe_log_err(tile, PCODE, ret, "timeout, retrying with preemption disabled\n");
>  	preempt_disable();
>  	ret = pcode_try_request(tile, mbox, request, reply_mask, reply, &status,
>  				true, 50 * 1000, true);

[Severity: High]
This is a pre-existing issue, but does this 50ms atomic timeout risk
integer overflow in udelay?

Looking at pcode_try_request, which is called here with atomic set to true:

static int pcode_try_request(..., bool atomic, int timeout_us, ...)
{
        int slept, wait = 10;
        ...
        for (slept = 0; slept < timeout_us; slept += wait) {
                ...
                if (atomic)
                        udelay(wait);
                else
                        usleep_range(wait, wait << 1);
                wait <<= 1;
        }
        ...
}

The wait variable grows exponentially without a cap. For a 50,000us timeout
loop, wait will repeatedly double and can reach well over 20,000us before the
timeout expires. This significantly exceeds typical architecture limits for
udelay, which are often around 1 to 2 milliseconds.

Can this uncapped exponential growth cause internal timer math to overflow
and trigger the hard lockup detector when firmware becomes unresponsive?

>  	preempt_enable();

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