On Mon, Sep 1, 2025 at 12:27 AM Boris Brezillon
<boris.brezil...@collabora.com> wrote:
<snipped>
> > diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
> > b/drivers/gpu/drm/panthor/panthor_sched.c
> > index ba5dc3e443d9c..62f17476e5852 100644
> > --- a/drivers/gpu/drm/panthor/panthor_sched.c
> > +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> > @@ -360,6 +360,9 @@ struct panthor_queue {
> > /** @entity: DRM scheduling entity used for this queue. */
> > struct drm_sched_entity entity;
> >
> > + /** @name: DRM scheduler name for this queue. */
> > + char name[32];
>
> The base string ("panthor-queue---") is already 16 characters. You then
> have a group ID that's below 128 IIRC, and a queue ID that's no more
> than 15, so that's 5 more chars. This leaves you 10 chars for the
> client ID (theoretically a 64-bit integer). I know the logic is sane
> because you truncate the string, but I'm wondering if we shouldn't make
> this string bigger to cover the theoretical max client_id, or simply
> dynamically allocate it (kasprintf()), so we don't have to think about
> it if we end up adding more stuff to the string.
It seems we don't validate queue count. Sending
https://lore.kernel.org/lkml/20250902192001.409738-1-olva...@gmail.com/
for that.
On a user device that opens the render node once per second, 10 chars
are good for 317 years. It lasts significantly shorter on a test
device, but the uptime is also significantly shorter on such a device
(hopefully).
But kasprintf should be harmless here. I can certainly switch to it.
