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

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

On Tue, Dec 21, 2010 at 09:43:01PM +0200, Nir Muchtar wrote:
> Jason Gunthorpe wrote:
> 
> > > But an RDMA CM ID is not a FD based resource. An event channel is, but I
> > > want to export ID stats and not event channel stats.
> > > Are you saying that there's a scenario in which an RDMA CM ID is shared
> > > between multiple processes?
> > 
> > It *is* a FD based resource. Nearly everything in Linux is.
> 
> Yes, nearly everything which is exported by Linux. but an RDMA CM ID
> is not a resource that has to be exported to the userspace.
> it's not FD based on its own.

But we are talking about a PID which primarily a userspace identifier.

> > It is tied to the ucma_fops FD (ie /dev/rdma_cm, aka the event
> > channel), which when closed calls ucma_free_ctx which calls
> > rdma_destroy_id. Processes that can access that FD can control the
> > RDMA CM IDs associated with it.

> Right. Like I already mentioned, an event channel is indeed FD based.
> However, an event channel doesn't (necessarily) have a one to one 
> relation with IDs.

So? Each RDMA CM ID is owned by userspace returns a reference to the
FD that owns it, and there can be many CM ID's referencing one FD.

> > The only case where this is not true is in the kernel, and in that
> > instance the PID is meaningless - you'd be much better off exporting
> > the name of the module that allocated the RDMA CM ID.

> But the PID is not meaningless in this case.  More often then not,
> the owner will be a kernel thread and will have a PID.

Well, there will always be a PID, it just might not be at all
informative (ie it could be kthreadd, ksoftirqd or something).  My
understanding was that actual named kernel threads are not really
preferred anymore, work queues/thread pool/etc are looking more
popular.. (eg http://lwn.net/Articles/347822/)

So I don't see the special case that kernel consumers don't have an
event channel FD as relevant. If you really care about this returning
the name of the module that created the ID is much more useful.

> but why should we rely on something that might control the ID when we 
> can rely on the ID itself? After all, this is the object we're really
> interested in.

The question is how do your correlate the kernel ID with the userspace
process(es) that have ownership of it. The only way to do that is to
associate the ID with the event channel FD with the process(es) that
have access to it.

Unfortunately there is no other way to correlate the in-kernel ID with
the process(es) that control it.

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