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? > > 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. But it's data include 'uverbs_obj_type_class' which has function pointers that are no longer valid after module unload. Can this be an issue? > means access to the IDR/FD function pointers is also guaranteed. Drivers > cannot define new types. > > This makes it safe to continue to use all uobjects, including driver > defined ones, after disassociation. > > Signed-off-by: Jason Gunthorpe <jgg@xxxxxxxxxxxx>
