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 <[email protected]> > > > --- > > > 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: [email protected] > > > +Description: > > > + Name of the plane. > > > + > > > What: > > > /sys/kernel/config/vkms/<device>/planes/<plane>/possible_crtcs > > > Date: Nov 2025 > > > Contact: [email protected] > > > 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 >
