On 5/19/2015 7:17 PM, Liran Liss wrote:
From: Hefty, Sean [mailto:sean.he...@intel.com]
these remaining resources may be device-specific.
The proposed framework first of all allows a provider to indicate
whether hot-removal is supported (i.e., the presence of the
'disassociate_ucontext' callback), and if so, allow the provider to
perform the proper cleanup so that the corresponding user-space driver
will continue to function.
The approach seems strange. The driver knows that it is being removed. It
was informed up front which open contexts were associated with user space
processes. But the driver calls up to indicate that it is being removed, so
that
the upper layer can call back down to tell the driver to process the removal.
I wasn't asking what this series did. I was asking why the uverbs driver just
can't delete the underlying resources. That's the natural thing to expect.
I suppose that the main issue would be handling existing user memory mappings,
which cannot be just invalidated -- the user-space driver may not be aware of
the
device removal and may access this memory concurrently, and we don't want it
to crash.
The meaning of these mappings is device specific: some devices only write them,
while others read them, expecting some specific format. That's why we need
device-specific code for this.
While it is true that the device initiates the removal process, the current
flow is
to let every ib_client first detach itself before device-specific cleanups. In
this regard,
ib_uverbs is just another client.
In addition, the "per-open" (fd) state is held in ib_ucontext, which is
maintained by
ib_uverbs. The device driver doesn't hold a duplicate list of open HCA handles,
so
it relies on ib_uverbs to iterate the relevant contexts and trigger the
device-specific
stuff.
Hi Doug,
Please see Liran's answer above, it clarified the need for that
approach. Can you please take into "for-next" ?
Yishai
--
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
