[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140828134957.GA6047@mail.hallyn.com>
Date: Thu, 28 Aug 2014 15:49:57 +0200
From: "Serge E. Hallyn" <serge@...lyn.com>
To: "chenhanxiao@...fujitsu.com" <chenhanxiao@...fujitsu.com>
Cc: Serge Hallyn <serge.hallyn@...ntu.com>,
"Richard Weinberger (richard@....at)" <richard@....at>,
"containers@...ts.linux-foundation.org"
<containers@...ts.linux-foundation.org>,
"Oleg Nesterov (oleg@...hat.com)" <oleg@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Eric W. Biederman (ebiederm@...ssion.com)" <ebiederm@...ssion.com>,
"Vasily Kulikov (segoon@...nwall.com)" <segoon@...nwall.com>
Subject: Re: [RFC]Pid conversion between pid namespace
Quoting chenhanxiao@...fujitsu.com (chenhanxiao@...fujitsu.com):
>
>
> > -----Original Message-----
> > From: Serge Hallyn [mailto:serge.hallyn@...ntu.com]
> > 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists