Re: [PATCH v3 07/33] drm/vkms: Introduce configfs for plane name

["José Expósito" <jose.exposito89@gmail.com>]

On Mon, Dec 29, 2025 at 03:40:23PM +0100, Louis Chauvet wrote:
> 
> 
> On 12/23/25 12:14, Luca Ceresoli wrote:
> > On Mon Dec 22, 2025 at 11:11 AM CET, Louis Chauvet wrote:
> > > Planes can have name, create a plane attribute to configure it. Currently
> > > plane name is mainly used in logs.
> > > 
> > > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > ---
> > >   Documentation/ABI/testing/configfs-vkms |  6 +++++
> > >   Documentation/gpu/vkms.rst              |  3 ++-
> > >   drivers/gpu/drm/vkms/vkms_configfs.c    | 43 +++++++++++++++++++++++++++++++++
> > >   3 files changed, 51 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/Documentation/ABI/testing/configfs-vkms b/Documentation/ABI/testing/configfs-vkms
> > > index 0beaa25f30ba..6fe375d1636f 100644
> > > --- a/Documentation/ABI/testing/configfs-vkms
> > > +++ b/Documentation/ABI/testing/configfs-vkms
> > > @@ -103,6 +103,12 @@ Description:
> > >           Plane type. Possible values: 0 - overlay, 1 - primary,
> > >           2 - cursor.
> > > 
> > > +What:		/sys/kernel/config/vkms/<device>/planes/<plane>/name
> > > +Date:		Nov 2025
> > > +Contact:	dri-devel@lists.freedesktop.org
> > > +Description:
> > > +        Name of the plane.
> > > +
> > >   What:		/sys/kernel/config/vkms/<device>/planes/<plane>/possible_crtcs
> > >   Date:		Nov 2025
> > >   Contact:	dri-devel@lists.freedesktop.org
> > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> > > index 1e79e62a6bc4..79f1185d8645 100644
> > > --- a/Documentation/gpu/vkms.rst
> > > +++ b/Documentation/gpu/vkms.rst
> > > @@ -87,10 +87,11 @@ Start by creating one or more planes::
> > > 
> > >     sudo mkdir /config/vkms/my-vkms/planes/plane0
> > > 
> > > -Planes have 1 configurable attribute:
> > > +Planes have 2 configurable attributes:
> > > 
> > >   - type: Plane type: 0 overlay, 1 primary, 2 cursor (same values as those
> > >     exposed by the "type" property of a plane)
> > > +- name: Name of the plane. Allowed characters are [A-Za-z1-9_-]
> > > 
> > >   Continue by creating one or more CRTCs::
> > > 
> > > diff --git a/drivers/gpu/drm/vkms/vkms_configfs.c b/drivers/gpu/drm/vkms/vkms_configfs.c
> > > index 506666e21c91..989788042191 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_configfs.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_configfs.c
> > > @@ -324,10 +324,53 @@ static ssize_t plane_type_store(struct config_item *item, const char *page,
> > >   	return (ssize_t)count;
> > >   }
> > > 
> > > +static ssize_t plane_name_show(struct config_item *item, char *page)
> > > +{
> > > +	struct vkms_configfs_plane *plane;
> > > +	const char *name;
> > > +
> > > +	plane = plane_item_to_vkms_configfs_plane(item);
> > > +
> > > +	scoped_guard(mutex, &plane->dev->lock)
> > > +		name = vkms_config_plane_get_name(plane->config);
> > 
> > vkms_config_plane_get_name() returns a pointer to the name string, not a
> > copy. Unless I'm missing something, that string might be freed before the
> > next lines, where it is used:
> > 
> > > +
> > > +	if (name)
> > > +		return sprintf(page, "%s\n", name);
> > > +	return sprintf(page, "\n");
> > 
> > So for safety the above 3 lines whould go inside the scoped_guard().
> 
> Good catch!
> 
> This also raised some questions on the whole locking synchronization between
> configfs / config / DRM core. I will work on this topic and maybe move the
> mutex / add a refcount to vkms_config.
> 
> > > +}
> > > +
> > > +static ssize_t plane_name_store(struct config_item *item, const char *page,
> > > +				size_t count)
> > > +{
> > > +	struct vkms_configfs_plane *plane;
> > > +	size_t str_len;
> > > +
> > > +	plane = plane_item_to_vkms_configfs_plane(item);
> > > +
> > > +	// strspn is not lenght-protected, ensure that page is a null-terminated string.
> > > +	str_len = strnlen(page, count);
> > > +	if (str_len >= count)
> > > +		return -EINVAL;
> > > +
> > > +	if (strspn(page, "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-") != count - 1)
> > > +		return -EINVAL;
> > 
> > I see you effor to make this as clean as possible, thanks. Still this is a
> > tad ugly, and should be moved to some common place at some point IMO. For
> > now it's fine, but if you need to add more user-passed strings, that could
> > be the moment to move this code.
> 
> There are multiple "user strings" in this file (notably group names), but
> currently without limitation.
> 
> I can create a tiny helper and limit all user strings to a-zA-Z0-9_-
> It will technically break the ABI, but I don't think this is a big issue.
> 
> Do you or José think this is a good idea? If so I can extract the helper for
> v4 and send a separate series to do the limitation on other strings.

From the top of my head, I think that at the moment the device name is the only
user facing string that is not limted in code? It is limited by the allowed
characters in filenames. But I might be forgetting other custom strings.

Technically, it'd be an ABI break... So, while I think it shouldn't be an issue,
I'd prefer to avoid breaking the ABI, but I leave the decision to you.

Jose
 
> > Luca
> > 
> > --
> > Luca Ceresoli, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
>