Hi,
On 4/29/21 1:40 PM, Daniel Vetter wrote:
> On Wed, Apr 28, 2021 at 11:52:49PM +0200, Hans de Goede wrote:
>> Userspace could hold open a reference to the connector->kdev device,
>> through e.g. holding a sysfs-atrtribute open after
>> drm_sysfs_connector_remove() has been called. In this case the connector
>> could be free-ed while the connector->kdev device's drvdata is still
>> pointing to it.
>>
>> Give drm_connector devices there own device type, which allows
>> us to specify our own release function and make drm_sysfs_connector_add()
>> take a reference on the connector object, and have the new release
>> function put the reference when the device is released.
>>
>> Giving drm_connector devices there own device type, will also allow
>> checking if a device is a drm_connector device with a
>> "if (device->type == &drm_sysfs_device_connector)" check.
>>
>> Note that the setting of the name member of the device_type struct will
>> cause udev events for drm_connector-s to now contain DEVTYPE=drm_connector
>> as extra info. So this extends the uevent part of the userspace API.
>>
>> Signed-off-by: Hans de Goede <hdego...@redhat.com>
>
> Are you sure? I thought sysfs is supposed to flush out any pending
> operations (they complete fast) and handle open fd internally?
So I did some digging in fs/kernfs and it looks like you right,
once the file has been removed from sysfs any accesses through an
open fd will fail with -ENODEV, interesting I did not know this.
We still need this change though to make sure that the
"drm/connector: Add drm_connector_find_by_fwnode() function"
does not end up following a dangling drvdat pointer from one
if the drm_connector kdev-s.
The class_dev_iter_init() in drm_connector_find_by_fwnode() gets
a reference on all devices and between getting that reference
and it calling drm_connector_get() - drm_connector_unregister()
may run and drop the possibly last reference to the
drm_connector object, freeing it and leaving the kdev's
drvdata as a dangling pointer.
But I obviously need to rewrite the commit message of this
commit as it currently is completely wrong.
Maybe I should even squash this into the commit adding
drm_connector_find_by_fwnode() ?
Note sure about that though I personally think this is best
kept as a new preparation patch but with a new commit msg.
> Also I'd assume this creates a loop since the connector holds a reference
> on the kdev?
So I was wondering the same thing when working on this code and
I checked. the reference on the kdev is dropped from:
drm_connector_unregister() -> drm_sysfs_connector_remove()
and then happens independent of the reference count on the
connector-drm-obj dropping to 0.
So what this change does is it keeps a reference to the
drm_connector obj as long as someone is keeping a reference
to the connnector->kdev device around after drm_connector_unregister()
but as soon as that kdev device ref is dropped, so will the
drm_connector's obj reference.
I also tested this using a dock with DP MST, which dynamically
adds/removes connectors on plug-in / plug-out of the dock-cable
and I added a printk to the new drm_sysfs_connector_release() this
adds and that printk triggered pretty much immediately on unplug
as expected, releasing the extra drm_connector obj as soon as
drm_connector_unregister() got called.
Regards,
Hans
> -Daniel
>
>> ---
>> drivers/gpu/drm/drm_sysfs.c | 54 +++++++++++++++++++++++++++++++------
>> 1 file changed, 46 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
>> index f0336c804639..c344c6d5e738 100644
>> --- a/drivers/gpu/drm/drm_sysfs.c
>> +++ b/drivers/gpu/drm/drm_sysfs.c
>> @@ -50,6 +50,10 @@ static struct device_type drm_sysfs_device_minor = {
>> .name = "drm_minor"
>> };
>>
>> +static struct device_type drm_sysfs_device_connector = {
>> + .name = "drm_connector",
>> +};
>> +
>> struct class *drm_class;
>>
>> static char *drm_devnode(struct device *dev, umode_t *mode)
>> @@ -271,30 +275,64 @@ static const struct attribute_group
>> *connector_dev_groups[] = {
>> NULL
>> };
>>
>> +static void drm_sysfs_connector_release(struct device *dev)
>> +{
>> + struct drm_connector *connector = to_drm_connector(dev);
>> +
>> + drm_connector_put(connector);
>> + kfree(dev);
>> +}
>> +
>> int drm_sysfs_connector_add(struct drm_connector *connector)
>> {
>> struct drm_device *dev = connector->dev;
>> + struct device *kdev;
>> + int r;
>>
>> if (connector->kdev)
>> return 0;
>>
>> - connector->kdev =
>> - device_create_with_groups(drm_class, dev->primary->kdev, 0,
>> - connector, connector_dev_groups,
>> - "card%d-%s", dev->primary->index,
>> - connector->name);
>> + kdev = kzalloc(sizeof(*kdev), GFP_KERNEL);
>> + if (!kdev)
>> + return -ENOMEM;
>> +
>> + device_initialize(kdev);
>> + kdev->class = drm_class;
>> + kdev->type = &drm_sysfs_device_connector;
>> + kdev->parent = dev->primary->kdev;
>> + kdev->groups = connector_dev_groups;
>> + kdev->release = drm_sysfs_connector_release;
>> + dev_set_drvdata(kdev, connector);
>> +
>> + r = dev_set_name(kdev, "card%d-%s", dev->primary->index,
>> connector->name);
>> + if (r)
>> + goto err_free;
>> +
>> DRM_DEBUG("adding \"%s\" to sysfs\n",
>> connector->name);
>>
>> - if (IS_ERR(connector->kdev)) {
>> - DRM_ERROR("failed to register connector device: %ld\n",
>> PTR_ERR(connector->kdev));
>> - return PTR_ERR(connector->kdev);
>> + r = device_add(kdev);
>> + if (r) {
>> + DRM_ERROR("failed to register connector device: %d\n", r);
>> + goto err_free;
>> }
>>
>> + /*
>> + * Ensure the connector object does not get free-ed if userspace still
>> has
>> + * references open to the device through e.g. the connector
>> sysfs-attributes.
>> + */
>> + drm_connector_get(connector);
>> +
>> + connector->kdev = kdev;
>> +
>> if (connector->ddc)
>> return sysfs_create_link(&connector->kdev->kobj,
>> &connector->ddc->dev.kobj, "ddc");
>> return 0;
>> +
>> +err_free:
>> + put_device(kdev);
>> + return r;
>> }
>>
>> void drm_sysfs_connector_remove(struct drm_connector *connector)
>> --
>> 2.31.1
>>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
