On Mon, Aug 13, 2018 at 03:18:08PM +0300, Shamir Rabinovitch wrote:
> On Thu, Aug 09, 2018 at 08:14:37PM -0600, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe <jgg@xxxxxxxxxxxx>
> >
> > Currently the struct uverbs_obj_type stored in the ib_uobject is part of
> > the .rodata segment of the module that defines the object. This is a
> > problem if drivers define new uapi objects as we will be left with a
> > dangling pointer after device disassociation.
>
> Just to clarify - 'after disassociation' == module unload - right?
Yes, in the cases we have today, module unload is required.
But as a general rule, after the ib_unregister_device the core code
should never touch any memory or call any functions provided by the
driver, this is just bad practice.
> > Switch the uverbs_obj_type for struct uverbs_api_object, which is
> > allocated memory that is part of the uverbs_api and is guaranteed to
> > always exist. Further this moves the 'type_class' into this memory which
>
> If issue is ro data access after module unload then the 'type_class' is
> now on kmalloc memory so it's ok to access it's data even after module
> unload.
'type_class' points to either uverbs_idr_class or uverbs_fd_class -
both of these are located in the uverbs module so are safe to use.
Further, the code has this:
/*
* Today drivers are only permitted to use
* idr_class types. They cannot use FD types
* because we currently have no way to revoke
* the fops pointer after device
* disassociation.
*/
if (WARN_ON(is_driver &&
obj->type_attrs->type_class !=
&uverbs_idr_class))
return -EINVAL;
Which prevents drivers from creating their own type_class in their own
module. This is not permitted today due to need to access the
type_class after disassoctiation.
Jason
