[PATCH 02/13] vfio/mdev: embedd struct mdev_parent in the parent data structure
Kirti Wankhede
kwankhede at nvidia.com
Fri Jun 24 12:29:58 UTC 2022
On 6/24/2022 1:48 AM, Jason Gunthorpe wrote:
> On Thu, Jun 16, 2022 at 12:59:47AM +0530, Kirti Wankhede wrote:
>
>>> @@ -110,7 +110,7 @@ static struct mdev_type *add_mdev_supported_type(struct mdev_parent *parent,
>>> type->kobj.kset = parent->mdev_types_kset;
>>> type->parent = parent;
>>> /* Pairs with the put in mdev_type_release() */
>>> - mdev_get_parent(parent);
>>> + get_device(parent->dev);
>>> type->type_group_id = type_group_id;
>>>
>>
>> Here device reference is held and release multiple times for each mdev_type.
>> It should be held once from mdev_register_parent() and released from
>> mdev_unregister_parent().
>
> It doesn't make any sense to put a paired references in the
> register/unregister on the struct device - the caller is already
> required to hold a reference until unregister completes.
>
then this need to be documented in the comment above.
> The reason this is here is because the type->parent is used in a few
> places and is put back in release:
>
> @@ -81,7 +81,7 @@ static void mdev_type_release(struct kobject *kobj)
>
> pr_debug("Releasing group %s\n", kobj->name);
> /* Pairs with the get in add_mdev_supported_type() */
> - mdev_put_parent(type->parent);
> + put_device(type->parent->dev);
> kfree(type);
> }
>
> If this was a simple sysfs kobj with only a show/store we wouldn't
> need to do anything as the natural kobj parentage holds a ref up to
> the struct device - but this kobj is used internally, ie dependent
> from mdev_device_create(), independently of the normal sysfs
> life-cycle so that doesn't protect enough either.
>
Life span of 'type' is from mdev_register_device to
mdev_unregister_device. If device/parent is being unregistered then only
types are removed, so referencing 'type' from mdev_device_create() is
still safe. Therefore, parent device's reference should be held and
release from register-unregister call.
Thanks,
Kirti
More information about the intel-gvt-dev
mailing list