From: Alessio Belle <Alessio.Belle@imgtec.com>
To: "pengpeng@iscas.ac.cn" <pengpeng@iscas.ac.cn>
Cc: Luigi Santivetti <Luigi.Santivetti@imgtec.com>,
"tzimmermann@suse.de" <tzimmermann@suse.de>,
"simona@ffwll.ch" <simona@ffwll.ch>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Frank Binns <Frank.Binns@imgtec.com>,
"maarten.lankhorst@linux.intel.com"
<maarten.lankhorst@linux.intel.com>,
"mripard@kernel.org" <mripard@kernel.org>,
"airlied@gmail.com" <airlied@gmail.com>
Subject: Re: [PATCH] drm/imagination: clamp freelist reconstruction requests
Date: Mon, 14 Sep 2026 15:34:32 +0000 [thread overview]
Message-ID: <86ca80fdd4d3d25bf2c08977e2ad961c5add7ac6.camel@imgtec.com> (raw)
In-Reply-To: <20260813152759.35856-1-pengpeng@iscas.ac.cn>
Hi Pengpeng,
Thanks for your patch and sorry the delay. A couple minor comments below.
On Thu, 2026-08-13 at 23:27 +0800, Pengpeng Hou wrote:
> The firmware reconstruction request contains a count followed by a
> fixed array of ROGUE_FWIF_MAX_FREELISTS_TO_RECONSTRUCT IDs. The host
> uses the count to walk the request array and to copy IDs into an equally
> sized response array without checking the protocol maximum.
>
> A firmware count above that maximum therefore makes both operations
> access beyond their protocol objects. Clamp the count to the array
> capacity, reconstruct only that bounded subset, and report the same
> bounded count to firmware. This follows the recovery contract confirmed
> by the firmware maintainers: an incomplete bounded update is preferable
> to an unrepresentable response and gives firmware a chance to recover.
>
> Warn once because an oversized count is a firmware bug, while avoiding
> repeated log flooding if firmware retries the malformed request.
>
> Fixes: 6eedddab733b ("drm/imagination: Implement free list and HWRT create and destroy ioctls")
> Assisted-by: Codex:gpt-5
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> Changes since the RFC: https://lore.kernel.org/all/20260722040942.85459-1-pengpeng@iscas.ac.cn/
> - implement the maintainer-confirmed bounded recovery policy
> - warn once when firmware exceeds the protocol array capacity
> - disclose the use of Codex
>
> The protocol extents and recovery path were reviewed statically. The
> change was not tested on PowerVR hardware.
>
> drivers/gpu/drm/imagination/pvr_free_list.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/imagination/pvr_free_list.c b/drivers/gpu/drm/imagination/pvr_free_list.c
> index e85cac83834c..23dbc227b081 100644
> --- a/drivers/gpu/drm/imagination/pvr_free_list.c
> +++ b/drivers/gpu/drm/imagination/pvr_free_list.c
> @@ -612,13 +612,20 @@ pvr_free_list_process_reconstruct_req(struct pvr_device *pvr_dev,
> };
> struct rogue_fwif_freelists_reconstruction_data *resp =
> &resp_cmd.cmd_data.free_lists_reconstruction_data;
> + u32 count = min_t(u32, req->freelist_count,
> + ARRAY_SIZE(req->freelist_ids));
>
> - for (u32 i = 0; i < req->freelist_count; i++)
> + if (count != req->freelist_count)
> + drm_warn_once(from_pvr_device(pvr_dev),
> + "Firmware requested reconstruction of %u freelists, limiting to %u\n",
> + req->freelist_count, count);
This triggers a build error because drm_warn_once() is not defined here.
Could you include drm_print.h at the top, after drm_gem.h?
Also could you wrap the "if" block in brackets since it spans multiple lines?
Lastly, up to you, but if you remove "Firmware", the log would still make sense
and the line would stay below 100 columns.
Thanks,
Alessio
> +
> + for (u32 i = 0; i < count; i++)
> pvr_free_list_reconstruct(pvr_dev, req->freelist_ids[i]);
>
> - resp->freelist_count = req->freelist_count;
> + resp->freelist_count = count;
> memcpy(resp->freelist_ids, req->freelist_ids,
> - req->freelist_count * sizeof(resp->freelist_ids[0]));
> + count * sizeof(resp->freelist_ids[0]));
>
> WARN_ON(pvr_kccb_send_cmd(pvr_dev, &resp_cmd, NULL));
> }
prev parent reply other threads:[~2026-09-14 15:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 15:27 Pengpeng Hou
2026-09-14 15:34 ` Alessio Belle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86ca80fdd4d3d25bf2c08977e2ad961c5add7ac6.camel@imgtec.com \
--to=alessio.belle@imgtec.com \
--cc=Frank.Binns@imgtec.com \
--cc=Luigi.Santivetti@imgtec.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=pengpeng@iscas.ac.cn \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®