Re: [PATCH V3 5/6] RDMA CM: Save Owning PID

Jason Gunthorpe
2010-12-22T22:10:56Z

On Wed, Dec 22, 2010 at 06:03:33PM +0200, Nir Muchtar wrote:

> Right now this is also the only practical way to export this
> information, because RDMA CM/UCM don't behave like sock does in terms of
> inode information.

Are you referring to how proc/fd currently shows
/dev/infiniband/rdma_cm for the link destination ?

I thought I saw something go by that added the struct file * address
or similar to proc/fdinfo/ but I see it did not get in. Grump.

> Also, in practice, many RDMA CM IDs are, in fact, created by the kernel
> (when new connections are established), so I'm not sure if what you're
> suggesting is even feasible with the current design of RDMA CM.

All RDMA CM IDs are assigned an idr number in ctx_idr and matched to a
ucma_file object before they become visible to userspace and thus
owned by a process. RDMA CM IDs that have not gone through this step
are floating about in the kernel and don't need to be matched to pids.

It is really straighfroward to do: run idr_for_each over ctx_idr, find the
ucma_contex->cm_id that matches the rdma_cm_id you are dumping, fill a
netlink attribute with the ctx id and something from
ucma_context->file to cross refrence with (the currently missing)
something in fdinfo. If you don't find an idr entry then don't emit
anything - it isn't exported to userspace.

Anyhow, I'd be happy if you stuck with creator_pid and left this for
future. But, you might want to consider dumping the ctx id from ucma -
since that is very useful.

Jason