On 13/07/2016 20:21, Jason Gunthorpe wrote:
On Wed, Jul 13, 2016 at 07:57:04PM +0300, Matan Barak wrote:
Maybe instead of having an idr per device, it's better to have an idr per
uverbs file.
Oh, I thought you were doing that already!
Yes, the idr must be per ucontext, otherwise we create a big security
problem. Access to one files object #'s cannot be allowed from another
file.
We don't have a security problem, as the ucontext pointer is store on
the uobject. Therefore, the uobject is returned only if it matches the
current ucontext.
However, when a device is removed, we need to find all its related objects
and destroy them. In order to do that in a simple way, we could say that a
uverbs_file is either not bound to any rdma device or bound to a
single IB
This is just more searching on the disassociate path. Search all
ucontexts for any uobj connected to the victim device.
If we drop the file == device scheme then we need a generic op to
tell what device a uobj is associated with. All our kobjs already
store this information, so it isn't a big deal.
I've thought about ditching the lists, but there's one fundamental
problem. Keeping reference counts in kernel doesn't encompass dependency
relations in the user space. For example, since memory windows could be
bounded and unbounded from a MR, we need to delete all MWs before
deleting the MRs.
Secondly, we could safely change the list to hlist. The memory overhead
will be minimal (probably better than adding and IDR per type).
If we break the file == device scheme, it also requires a few new object
types (for example, DEVICE and CLIENT object) to pass them from user-space.
So the flow might be using the QUERY ioctl code and query the
devices/clients. Creating a device/client and get a IDR handle for that.
For every IOCTL code (either device or client commands), you pass this
idr handle as part of the ioctl code specific header.
However, does it really worth it? Do you see any usage of binding the
same uverbs_file to several rdma devices?
If not, we could have a simpler approach of having a file either bounded
to a device or not bounded to any device. We could still share the IDR
with clients on the same fd, but they are all guaranteed to set or use
this exact device.
Jason
Matan
--
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
