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

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html