On Thu, Aug 09, 2018 at 07:53:04PM +0000, Ruhl, Michael J wrote: > >It is not a new limitation, it was always true, we just didn't check > >for it before.. > > > >The problem is how to handle the fops during disassociation, as the > >fops pointer points to the driver, and the driver module can become > >unloaded. > > > >I guess it would be fine if the driver sets struct > >file_operations->owner to THIS_MODULE - maybe we should just check for > >that here. > > > >It means disassocation via module unload doesn't work if the driver > >creates an FD, which is probably OK. > > > >This is a tricky area, I prefer to leave it blocked until we have an > >example driver user to study to get the lifetime right. > > Ahh. Ok, all my experimentation has been with how to know when > to close the FD when destroying the object. I didn't think about what > happens during driver unload. You can't close a FD unilaterally, only user space can close the FD. So FD objects have to continue to exist beyond close of the ufile fd, and if necessary, should hold a kref on the ufile.. > >> >+ * Called when a driver disassociates from the ib_uverbs_device. The > >> >+ * assumption is that the driver module will unload after. Replace > >eveything > ^^^^^^^^^ > "everything" got it Thanks Jason
