From: ebiederm@xmission.com (Eric W. Biederman)
To: Vasily Kulikov <segoon@openwall.com>
Cc: Pavel Emelyanov <xemul@parallels.com>,
Richard Weinberger <richard.weinberger@gmail.com>,
containers@lists.linux-foundation.org,
Serge Hallyn <serge.hallyn@ubuntu.com>,
linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
David Howells <dhowells@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v2] /proc/pid/status: show all sets of pid according to ns
Date: Sat, 31 May 2014 13:08:01 -0700 [thread overview]
Message-ID: <87egz9lnj2.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20140531060713.GA5315@cachalot> (Vasily Kulikov's message of "Sat, 31 May 2014 10:07:13 +0400")
Vasily Kulikov <segoon@openwall.com> writes:
> On Thu, May 29, 2014 at 16:53 +0400, Pavel Emelyanov wrote:
>> On 05/29/2014 03:59 PM, Vasily Kulikov wrote:
>> > On Thu, May 29, 2014 at 15:31 +0400, Pavel Emelyanov wrote:
>> >> On 05/29/2014 03:12 PM, Vasily Kulikov wrote:
>> >>> On Thu, May 29, 2014 at 13:07 +0400, Pavel Emelyanov wrote:
>> >>>> On 05/29/2014 09:59 AM, Vasily Kulikov wrote:
>> >>>>> On Wed, May 28, 2014 at 23:27 +0400, Pavel Emelyanov wrote:
>> >>>>> ] We need a direct method of getting the pid inside containers.
>> >>>>> ] If some issues occurred inside container guest, host user
>> >>>>> ] could not know which process is in trouble just by guest pid:
>> >>>>> ] the users of container guest only knew the pid inside containers.
>> >>>>> ] This will bring obstacle for trouble shooting.
>> >>>>>
>> >>>>> A new syscall might complicate trouble shooting by admin.
>> >>>>
>> >>>> Pure syscall -- yes. What if we teach the ps and top utilities to show additional
>> >>>> info? I think that would help.
>> >>>
>> >>> I like the idea with low level non-shell API which can be used by
>> >>> utility like ps (or implementation of a new tool to work with complex
>> >>> namespace hierarchies). It should fit for troublesooting. Then there
>> >>> should be no reason to implement two different APIs for observation from
>> >>> shell via FS and from applications.
>> >>
>> >> Maybe we can reuse the existing kcmp() system call? We would have to store
>> >> the collected pid values in some hash/tree anyway, and kcmp() provides us
>> >> good comparing function for doing this.
>> >>
>> >> Like we can call kcmp(pid1, pid2, KCMP_PID, nsfd1, nsfd2) which will mean
>> >> "Are tasks with pid1 in namespace pointed by nsfd1 and with pid2 in namespace
>> >> nsfd2 the same?"
>> >>
>> >> What do you think?
>> >
>> > kcmp() is not needed, just compare inode numbers:
>> >
>> > # ls -il /proc/{43,self}/ns/mnt
>> > 208182 lrwxrwxrwx 1 root root 0 мая 29 15:52 /proc/43/ns/mnt -> mnt:[4026531856]
>> > 216556 lrwxrwxrwx 1 root root 0 мая 29 15:57 /proc/self/ns/mnt -> mnt:[4026531840]
>>
>> But that's for comparing the namespaces, while I'm proposing the kcmp to
>> check for PIDs.
>
> Hm, right.
>
> What about the following solution: export global process ID (PID in
> init ns) which is visible inside of any namespace. Then you can compare
> numbers regardless in what namespace you are.
Which then defeats the point of having pid namespaces in the first
place.
How do you get that same global pid after you have migrated your
container?
Eric
prev parent reply other threads:[~2014-05-31 20:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-28 10:24 Chen Hanxiao
2014-05-28 12:44 ` Pavel Emelyanov
2014-05-28 18:28 ` Vasily Kulikov
2014-05-28 19:27 ` Pavel Emelyanov
2014-05-29 5:59 ` Vasily Kulikov
2014-05-29 9:07 ` Pavel Emelyanov
2014-05-29 9:21 ` Richard Weinberger
2014-05-29 9:41 ` Pavel Emelyanov
2014-05-29 9:54 ` Richard Weinberger
2014-05-29 10:02 ` Pavel Emelyanov
2014-05-29 10:19 ` Richard Weinberger
2014-05-29 10:36 ` Pavel Emelyanov
2014-05-29 9:53 ` chenhanxiao
2014-05-29 10:40 ` Pavel Emelyanov
2014-05-29 11:12 ` Vasily Kulikov
2014-05-29 11:31 ` Pavel Emelyanov
2014-05-29 11:59 ` Vasily Kulikov
2014-05-29 12:53 ` Pavel Emelyanov
2014-05-31 6:07 ` Vasily Kulikov
2014-05-31 20:08 ` Eric W. Biederman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87egz9lnj2.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=richard.weinberger@gmail.com \
--cc=segoon@openwall.com \
--cc=serge.hallyn@ubuntu.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome