Re: [PATCH v2] drm/imagination: Improve logging of unknown freelist IDs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/imagination: missing lock around free_list page accounting
--

commit 26a8dc61d661134bbaa586ea04b036fc6a817608
Author: Alessio Belle <alessio.belle@imgtec.com>
drm/imagination: Improve logging of unknown freelist IDs

This commit improves logging when the driver receives freelist grow or
reconstruction requests from the firmware for unrecognised freelist IDs.
It replaces a WARN_ON() with a ratelimited warning.

Link: https://patch.msgid.link/20261006-b4-improve-logging-of-unknown-freelist-ids-v1-1-96ebcb132b80@imgtec.com

> diff --git a/drivers/gpu/drm/imagination/pvr_free_list.c b/drivers/gpu/drm/imagination/pvr_free_list.c
> index e85cac83834c6..ec02fbbe0168b 100644
> --- a/drivers/gpu/drm/imagination/pvr_free_list.c
> +++ b/drivers/gpu/drm/imagination/pvr_free_list.c
[ ... ]
> @@ -367,8 +368,12 @@ void pvr_free_list_process_grow_req(struct pvr_device *pvr_dev,
>  	u32 grow_pages = 0;
>  
>  	/* If we don't have a freelist registered for this ID, we can't do much. */
> -	if (WARN_ON(!free_list))
> +	if (!free_list) {
> +		drm_warn_ratelimited(from_pvr_device(pvr_dev),
> +				     "Received freelist grow request for unknown ID 0x%x\n",
> +				     req->freelist_id);
>  		return;
> +	}
>  
>  	/* Since the FW made the request, it has already consumed the ready pages,
>  	 * update the host struct.

[Severity: High]
Are there missing locks around the free_list page accounting in
pvr_free_list_process_grow_req()?

Right below this change, free_list->current_pages and free_list->ready_pages are
modified without holding free_list->lock:

	free_list->current_pages += free_list->ready_pages;
	free_list->ready_pages = 0;

The FWCCB processing loop (pvr_fwccb_process) drops pvr_dev->fwccb.lock before
calling process_fwccb_command().

Since pvr_fwccb_process() is called by both the IRQ thread
(pvr_device_irq_thread_handler) and the release path (pvr_free_list_release),
could multiple threads concurrently pull commands from the global FWCCB queue?

If pvr_free_list_release() runs concurrently with the IRQ thread, it appears
they could execute pvr_free_list_process_grow_req() or
pvr_free_list_reconstruct() for the same freelist concurrently.

Could this result in a data race and corrupted page tracking, causing the
firmware to access unmapped or unallocated memory (GPU MMU fault)?

Additionally, after pvr_free_list_grow() returns, the fields are read again
without holding the lock:

	resp->new_pages = free_list->current_pages + free_list->ready_pages;
	resp->ready_pages = free_list->ready_pages;

Could this create a time-of-check to time-of-use vulnerability where the values
are modified by another thread before being used to populate the response?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009-b4-improve-logging-of-unknown-freelist-ids-v2-1-5e6c3f63370e@imgtec.com?part=1