public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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