Re: [RFC]Pid conversion between pid namespace

[Serge E. Hallyn]

Quoting chenhanxiao@xxxxxxxxxxxxxx (chenhanxiao@xxxxxxxxxxxxxx):
> 
> 
> > -----Original Message-----
> > From: Serge Hallyn [mailto:serge.hallyn@xxxxxxxxxx]
> > Sent: Friday, August 08, 2014 12:12 AM
> > To: Chen, Hanxiao/é æé
> 
> > > > How much more kernel space does this take up?
> > > >
> > >
> > > Only first process when creating new ns will be add here.
> > > So there would not so many items.
> > 
> > Oh, I see.
> > 
> > > > Is there an easy way to go from a pid in your own namespace
> > > > to its proper node under /proc/nspid?  I.e. if I am interested
> > > > in pid 9987, which happens to be pid 5 inside a container in
> > > > ns2, and then I want to know what it means when it (pid 9987)
> > > > is talking about 'pid 10'.  Is there a link under /proc/9987/
> > > > leading to /proc/nspid/ns2/5 ?
> > >
> > > If you want to query pid 9987, you could:
> > > a) readlink /proc/9987/ns/pid
> > > b) refer to /proc/nspid/ns$(inum)/ns$(inum)..
> > > c) Also the link to the 1st new ns process could be found under ns$(inum).
> > 
> > This is good.  Let's go with it.
> 
> OK
> 
> > 
> > > Or as what you said above,
> > 
> > Nah.  Let's not change /proc/PID/ns/pid.
> > 
> > > > This sure does seem the simplest route.  But it actually still
> > > > does not provide us an easy answer to "what does pid 9987 mean
> > > > when it talks about pid 10?".
> > >
> > > Do you mean:
> > > init_pid_ns   ns1     ns2
> > > 9987            10      5
> > > Neither getnspid syscall nor proc/PID/status expansion
> > > could answer this without hierarchy information.
> > > For users in init_pid_ns, getnspid needs
> > > an observer pid live and only live in ns1,
> > 
> > Yes, good point.  That's a definite disadvantage of getnspid
> > compared to your proc approach.
> > 
> > > or we should call getnspid in ns1.
> > > See below for more.
> > >
> > > >
> > > > > 2. Advantage of procfs solution
> > > > > a) easy to use:
> > > > > getnspid(6, 10) -> (10, 9, 10)
> > > > > or
> > > > > getnspid(10, ns1_fd, ns0_fd) -> 9
> > > > > getnspid(10, ns2_fd, ns0_fd) -> 10
> > > > >
> > > > > And we could also get it by:
> > > > > cat /proc/10/status | grep NSpid:
> > > > > NSpid:	10 	9 	10
> > > > > ...
> > > >
> > > > It looks nice, but I'm not convinced it gives us the info we
> > > > need.
> > > >
> > > > It's certainly possible that I've just not thought it through
> > > > enough.
> > > >
> > > > Question: are you proposing this (/proc/pid/status expansion) as an
> > > > alternative to /proc/nspid, or are they meant to be complementary?
> > > >
> > >
> > > We want /proc/nspid as a complement for pid translation.
> > 
> > Ok.
> > 
> > > Ex:
> > >     init_pid_ns     ns1         ns2
> > > t1  2
> > > t2   `- 3           1
> > > t3       `- 4       `- 5        1
> > > t4           `-6        `-8      `-9
> > > t5             `-10        `-9      `-10
> > > Suppose we were in init_pid_ns:
> > > getnspid(9,4)->6 (t4)
> > > getnspid(9,3)->10(t5)
> > > We knew t2 in ns1 and t3 in ns2, but we don't know their relationship.
> > > If we want to query pid 9 in ns1, we could use getnspid(9,3)->10(t5)
> > > but the pre-requisite is that we know ns2 is the child of ns1.
> > 
> > I like your proc approach.  Do you have an implementation?
> 
> Thanks for your comments.
> I'm preparing the pidns hierarchy patch.
> It seems that it's not easy to carry it out.

:)  Not entirely surprised.

Please do send patches earlier rather than later to avoid going
down a path that someone's going to nack anyway.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/