Hi Jason, On 10/17/2016 09:07 AM, Jason Gunthorpe wrote: >> + atomic_inc(&dd->user_refcount); > This doesn't look like enough locking on acquire.. What prevents the > driver from already having been unloaded at this point? Thanks for your feedback. We will address this in v2. > > Shouldn't this be a while loop to avoid races? > > .. and shouldn't the inc 'latch off' once the removal process starts? > > I think you need to study how kernfs_drain is implemented and > basically copy that approach, including the locking. as to kernfs_drain approach, I think the same mechanism as in ib_verbs will work better here. > > FWIW, it is much easier and probably long term better to arrange > things so the FD can remain open but just return ENODEV to all calls. > Eg the srcu based approach in uverbs. We need to hold the device because not all the clients will talk to the device via the FD. The PIO clients for instance don't go to kernel. Thanks, -- TS -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
