> On 7/17/2014 9:01 AM, Devesh Sharma wrote:
> > If verndor driver is attempted for removal while xprtrdma still has an
> > active mount, the removal of driver may never complete and can cause
> > unseen races or in worst case system crash.
> >
> > To solve this, xprtrdma module should get reference of struct ib_device
> > structure for every mount. Reference is taken after local device address
> > resolution is completed successfuly.
> >
> > reference to the struct ib_device pointer is put just before cm_id
> destruction.
> >
> > Signed-off-by: Devesh Sharma <devesh.sha...@emulex.com>
>
> This seems like an issue with the rdma-cm or rdma core, not xprtrdma. I
> see that user rdma applications cause a ref on the provider module here
> in ib_uverbs_open():
>
> if (!try_module_get(dev->ib_dev->owner)) {
> ret = -ENODEV;
> goto err;
>
>
> Maybe kernel applications that allocate device resources should cause a
> ref on the provider's module.
>
> Sean/Roland, is there some history here as to how rdma provider module
> removal should be handled?
The kernel modules should are not expected to access the rdma devices after
their remove device callback has been invoked. The rdma cm basically forwards
the device removal on a per id basis. Apps are expected to destroy the id
after receiving that callback. The rdma cm should block in the remove device
call until all id's associated with the removed device have been destroyed.
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
