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? > > > > > 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? > Ah, I see this is taken care in 'uverbs_disassociate_api' in this line "object_elm->type_attrs = NULL;" So just wonder if there is need to do the same for 'object_elm->type_class' pointer. > > 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>
