From: Louis Chauvet <louis.chauvet@bootlin.com>
To: "José Expósito" <jose.exposito89@gmail.com>
Cc: hamohammed.sa@gmail.com, simona@ffwll.ch, melissa.srw@gmail.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 03/16] drm/vkms: Allow to configure multiple planes via configfs
Date: Fri, 28 Feb 2025 15:43:25 +0100 [thread overview]
Message-ID: <52bc3f15-28da-4b40-917f-981f1f10d9b8@bootlin.com> (raw)
In-Reply-To: <20250225175936.7223-4-jose.exposito89@gmail.com>
Le 25/02/2025 à 18:59, José Expósito a écrit :
> Create a default subgroup at /config/vkms/planes to allow to create as
> many planes as required.
>
> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> Co-developed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
> Signed-off-by: José Expósito <jose.exposito89@gmail.com>
> ---
> Documentation/gpu/vkms.rst | 16 ++++-
> drivers/gpu/drm/vkms/vkms_configfs.c | 87 ++++++++++++++++++++++++++++
> 2 files changed, 102 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> index 423bdf86b5b1..bf23d0da33fe 100644
> --- a/Documentation/gpu/vkms.rst
> +++ b/Documentation/gpu/vkms.rst
> @@ -71,6 +71,19 @@ By default, the instance is disabled::
> cat /config/vkms/my-vkms/enabled
> 0
>
> +And directories are created for each configurable item of the display pipeline::
> +
> + tree /config/vkms/my-vkms
> + ├── enabled
> + └── planes
> +
> +To add items to the display pipeline, create one or more directories under the
> +available paths.
> +
> +Start by creating one or more planes::
> +
> + sudo mkdir /config/vkms/my-vkms/planes/plane0
> +
> Once you are done configuring the VKMS instance, enable it::
>
> echo "1" | sudo tee /config/vkms/my-vkms/enabled
> @@ -79,8 +92,9 @@ Finally, you can remove the VKMS instance disabling it::
>
> echo "0" | sudo tee /config/vkms/my-vkms/enabled
>
> -And removing the top level directory::
> +And removing the top level directory and its subdirectories::
>
> + sudo rmdir /config/vkms/my-vkms/planes/*
> sudo rmdir /config/vkms/my-vkms
>
> Testing With IGT
> diff --git a/drivers/gpu/drm/vkms/vkms_configfs.c b/drivers/gpu/drm/vkms/vkms_configfs.c
> index 92512d52ddae..4f9d3341e6c0 100644
> --- a/drivers/gpu/drm/vkms/vkms_configfs.c
> +++ b/drivers/gpu/drm/vkms/vkms_configfs.c
> @@ -16,6 +16,7 @@ static bool is_configfs_registered;
> *
> * @group: Top level configuration group that represents a VKMS device.
> * Initialized when a new directory is created under "/config/vkms/"
> + * @planes_group: Default subgroup of @group at "/config/vkms/planes"
> * @lock: Lock used to project concurrent access to the configuration attributes
> * @config: Protected by @lock. Configuration of the VKMS device
> * @enabled: Protected by @lock. The device is created or destroyed when this
> @@ -23,16 +24,98 @@ static bool is_configfs_registered;
> */
> struct vkms_configfs_device {
> struct config_group group;
> + struct config_group planes_group;
>
> struct mutex lock;
> struct vkms_config *config;
> bool enabled;
> };
>
> +/**
> + * struct vkms_configfs_plane - Configfs representation of a plane
> + *
> + * @group: Top level configuration group that represents a plane.
> + * Initialized when a new directory is created under "/config/vkms/planes"
> + * @dev: The vkms_configfs_device this plane belongs to
> + * @config: Configuration of the VKMS plane
> + */
> +struct vkms_configfs_plane {
> + struct config_group group;
> + struct vkms_configfs_device *dev;
> + struct vkms_config_plane *config;
> +};
> +
> #define device_item_to_vkms_configfs_device(item) \
> container_of(to_config_group((item)), struct vkms_configfs_device, \
> group)
>
> +#define child_group_to_vkms_configfs_device(group) \
> + device_item_to_vkms_configfs_device((&(group)->cg_item)->ci_parent)
> +
> +#define plane_item_to_vkms_configfs_plane(item) \
> + container_of(to_config_group((item)), struct vkms_configfs_plane, group)
> +
> +static void plane_release(struct config_item *item)
> +{
> + struct vkms_configfs_plane *plane;
> + struct mutex *lock;
> +
> + plane = plane_item_to_vkms_configfs_plane(item);
> + lock = &plane->dev->lock;
> +
> + guard(mutex)(lock);
> + vkms_config_destroy_plane(plane->config);
> + kfree(plane);
> +}
I just found a flaw in our work: there is currently no way to forbid the
deletion of item/symlinks...
If you do:
modprobe vkms
cd /sys/kernel/config/vkms/
mkdir DEV
mkdir DEV/connectors/CON
mkdir DEV/planes/PLA
mkdir DEV/crtcs/CRT
mkdir DEV/encoders/ENC
ln -s DEV/crtcs/CRT DEV/planes/PLA/possible_crtcs/
ln -s DEV/crtcs/CRT DEV/encoders/ENC/possible_crtcs
ln -s DEV/encoders/ENC DEV/connectors/CON/possible_encoders
echo 1 > DEV/planes/PLA/type
tree
echo 1 > DEV/enabled
modetest -M vkms
=> everything fine
rm DEV/connectors/CON/possible_encoders/ENC
rmdir DEV/connectors/CON
modetest -M vkms
=> BUG: KASAN: slab-use-after-free
I see two solutions:
- we don't care and keep as is: if the device is enabled, and you delete
link/groups, it is your fault. As shown above: it can crash the kernel,
so it is a no-go.
- we care and we don't want to touch configfs: we need to implement a
kind of refcount for all vkms_config elements. Issue: non-trivial work,
may allow memory leaks/use after free...
- we care and we want to touch configfs: see my two patches (they apply
on the v1 of this series). This solution allows adding a check before
removing configfs item/group/link. I found it cleaner and way easier to
understand.
What do you think about my proposition? Do you have another idea?
> +static struct configfs_item_operations plane_item_operations = {
> + .release = &plane_release,
> +};
> +
> +static const struct config_item_type plane_item_type = {
> + .ct_item_ops = &plane_item_operations,
> + .ct_owner = THIS_MODULE,
> +};
> +
> +static struct config_group *make_plane_group(struct config_group *group,
> + const char *name)
> +{
> + struct vkms_configfs_device *dev;
> + struct vkms_configfs_plane *plane;
> +
> + dev = child_group_to_vkms_configfs_device(group);
> +
> + guard(mutex)(&dev->lock);
> +
> + if (dev->enabled)
> + return ERR_PTR(-EBUSY);
> +
> + plane = kzalloc(sizeof(*plane), GFP_KERNEL);
> + if (!plane)
> + return ERR_PTR(-ENOMEM);
> +
> + plane->dev = dev;
> +
> + plane->config = vkms_config_create_plane(dev->config);
> + if (IS_ERR(plane->config)) {
> + kfree(plane);
> + return ERR_CAST(plane->config);
> + }
> +
> + config_group_init_type_name(&plane->group, name, &plane_item_type);
> +
> + return &plane->group;
> +}
> +
> +static struct configfs_group_operations planes_group_operations = {
> + .make_group = &make_plane_group,
> +};
> +
> +static const struct config_item_type plane_group_type = {
> + .ct_group_ops = &planes_group_operations,
> + .ct_owner = THIS_MODULE,
> +};
> +
> static ssize_t device_enabled_show(struct config_item *item, char *page)
> {
> struct vkms_configfs_device *dev;
> @@ -125,6 +208,10 @@ static struct config_group *make_device_group(struct config_group *group,
> config_group_init_type_name(&dev->group, name, &device_item_type);
> mutex_init(&dev->lock);
>
> + config_group_init_type_name(&dev->planes_group, "planes",
> + &plane_group_type);
> + configfs_add_default_group(&dev->planes_group, &dev->group);
> +
> return &dev->group;
> }
>
--
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2025-02-28 14:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-25 17:59 [PATCH v2 00/16] drm/vkms: Add configfs support José Expósito
2025-02-25 17:59 ` [PATCH v2 01/16] drm/vkms: Expose device creation and destruction José Expósito
2025-02-25 17:59 ` [PATCH v2 02/16] drm/vkms: Add and remove VKMS instances via configfs José Expósito
2025-02-28 15:19 ` Louis Chauvet
2025-03-03 8:33 ` José Expósito
2025-02-25 17:59 ` [PATCH v2 03/16] drm/vkms: Allow to configure multiple planes " José Expósito
2025-02-28 14:43 ` Louis Chauvet [this message]
2025-03-03 8:50 ` José Expósito
2025-03-03 10:34 ` Louis Chauvet
2025-03-04 14:54 ` José Expósito
2025-03-04 15:35 ` Louis Chauvet
2025-03-04 16:23 ` José Expósito
2025-03-04 18:17 ` Louis Chauvet
2025-03-06 10:49 ` José Expósito
2025-02-28 14:43 ` [PATCH 2/2] configfs: Add mechanism to prevent item/group deletion Louis Chauvet
2025-02-28 14:43 ` [PATCH 1/2] configfs: Add mechanism to prevent symlink deletion Louis Chauvet
2025-02-25 17:59 ` [PATCH v2 04/16] drm/vkms: Allow to configure the plane type via configfs José Expósito
2025-02-25 17:59 ` [PATCH v2 05/16] drm/vkms: Allow to configure multiple CRTCs " José Expósito
2025-02-25 17:59 ` [PATCH v2 06/16] drm/vkms: Allow to configure CRTC writeback support " José Expósito
2025-02-25 17:59 ` [PATCH v2 07/16] drm/vkms: Allow to attach planes and CRTCs " José Expósito
2025-02-25 17:59 ` [PATCH v2 08/16] drm/vkms: Allow to configure multiple encoders " José Expósito
2025-02-25 17:59 ` [PATCH v2 09/16] drm/vkms: Allow to attach encoders and CRTCs " José Expósito
2025-02-25 17:59 ` [PATCH v2 10/16] drm/vkms: Allow to configure multiple connectors " José Expósito
2025-02-25 17:59 ` [PATCH v2 11/16] drm/vkms: Allow to attach connectors and encoders " José Expósito
2025-02-25 17:59 ` [PATCH v2 12/16] drm/vkms: Allow to configure the default device creation José Expósito
2025-02-25 17:59 ` [PATCH v2 13/16] drm/vkms: Remove completed task from the TODO list José Expósito
2025-02-25 17:59 ` [PATCH v2 14/16] drm/vkms: Allow to configure connector status José Expósito
2025-02-25 17:59 ` [PATCH v2 15/16] drm/vkms: Allow to update the " José Expósito
2025-02-25 17:59 ` [PATCH v2 16/16] drm/vkms: Allow to configure connector status via configfs José Expósito
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=52bc3f15-28da-4b40-917f-981f1f10d9b8@bootlin.com \
--to=louis.chauvet@bootlin.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamohammed.sa@gmail.com \
--cc=jose.exposito89@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=melissa.srw@gmail.com \
--cc=mripard@kernel.org \
--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