From: Kirill Korotaev <dev@sw.ru>
To: Herbert Poetzl <herbert@13thfloor.at>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
"Serge E. Hallyn" <serue@us.ibm.com>,
linux-kernel@vger.kernel.org, vserver@list.linux-vserver.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Dave Hansen <haveblue@us.ibm.com>,
Arjan van de Ven <arjan@infradead.org>,
Suleiman Souhlal <ssouhlal@FreeBSD.org>,
Hubertus Franke <frankeh@watson.ibm.com>,
Cedric Le Goater <clg@fr.ibm.com>,
Kyle Moffett <mrmacman_g4@mac.com>, Greg <gkurz@fr.ibm.com>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
Greg KH <greg@kroah.com>, Rik van Riel <riel@redhat.com>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Andrey Savochkin <saw@sawoct.com>,
Kirill Korotaev <dev@openvz.org>, Andi Kleen <ak@suse.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Jeff Garzik <jgarzik@pobox.com>,
Trond Myklebust <trond.myklebust@fys.uio.no>,
Jes Sorensen <jes@sgi.com>
Subject: Re: (pspace,pid) vs true pid virtualization
Date: Mon, 20 Feb 2006 12:50:02 +0300 [thread overview]
Message-ID: <43F990CA.5080102@sw.ru> (raw)
In-Reply-To: <20060216143030.GA27585@MAIL.13thfloor.at>
Hello,
>>- Should any children of pid 1 be allowed to live
>> when pid == 1 is killed?
> agan that's a feature which would be nice, especially
> for the lightweight contexts, which do not have an init
> process running inside the guest
whom should child_reaper refer to?
>>- Should a process have some sort of global (on the machine identifier)?
> this is mandatory, as it is required to kill any process
> from the host (admin) context, without entering the pid
> space (which would lead to all kind of security issues)
fine, agreed on this finally, same for OpenVZ.
>>- Should the pids in a pid space be visible from the outside?
> yes, while not strictly required, folks really like to
> view the overall system state. this can be done with the
> help of special tools, but again it should be done
> without entering each guest pid space ...
also fine.
>>- Should the parent of pid 1 be able to wait for it for it's
>> children?
> definitely, we (Linux-VServer) added this some time ago
> and it helps to maintain/restart a guest.
but why sys_waitpid? we can make it in many other ways,
can't we? moreover, sys_waitpid() is the most unnatural from my point of
view, since container is not fully dead when the last process dies, it
makes some cleanup postponed.
And we had issues in OpenVZ, that very fast VPS stop/start can fail due
to not freed resources yet.
>>- Is a completely disjoin pid space acceptable to anyone?
> yes, as long as the beforementioned access, management
> and control mechanisms are in place ...
then it is not disjoin? :)
>>- What should the parent of pid == 1 see?
> doesn't really matter, but I see three options there:
>
> - the parent space
> - the child space
> - both
but should parent see pspace init? only one task from pspace?
>>- Should we be able to monitor a pid space from the outside?
> yes, definitely, but it could happen via some special
> interfaces, i.e. no need to make it compatible
disagree. why we need to introduce copy of existing syscalls?
do you want to fix all the existing apps? ps, top, kill etc.? How about
third party apps?
>>- Should we be able to have processes enter a pid space?
> definitely, without that, the entire VPS concept will
> not work, folks use the 'admin' backdoors 90% of the
> time ...
agreed. Though I don't like a backdoor name :) It is just a way to get
access to VPS.
Kirill
next prev parent reply other threads:[~2006-02-20 9:48 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-15 14:59 (pspace,pid) vs true pid virtualization Serge E. Hallyn
2006-02-15 22:12 ` Eric W. Biederman
2006-02-16 14:29 ` Serge E. Hallyn
2006-02-16 16:37 ` Eric W. Biederman
2006-02-16 17:53 ` Serge E. Hallyn
2006-02-16 18:19 ` Eric W. Biederman
2006-02-16 18:44 ` Serge E. Hallyn
2006-02-16 18:52 ` Dave Hansen
2006-02-17 10:57 ` Eric W. Biederman
2006-02-17 11:44 ` Herbert Poetzl
2006-02-17 12:16 ` Eric W. Biederman
2006-02-17 12:44 ` Herbert Poetzl
2006-02-17 13:15 ` Eric W. Biederman
2006-02-17 13:39 ` Hubertus Franke
2006-02-17 21:40 ` Herbert Poetzl
2006-02-17 11:04 ` Eric W. Biederman
2006-02-20 10:06 ` Kirill Korotaev
2006-02-17 3:35 ` Hubertus Franke
2006-02-17 14:53 ` Serge E. Hallyn
2006-02-20 9:37 ` Kirill Korotaev
2006-02-20 12:47 ` Herbert Poetzl
2006-02-20 14:34 ` Kirill Korotaev
2006-02-20 15:27 ` Herbert Poetzl
2006-02-16 14:30 ` Herbert Poetzl
2006-02-16 15:37 ` Serge E. Hallyn
2006-02-16 17:13 ` Eric W. Biederman
2006-02-16 17:57 ` Serge E. Hallyn
2006-02-20 9:54 ` Kirill Korotaev
2006-02-20 18:19 ` Dave Hansen
2006-02-16 16:59 ` Eric W. Biederman
2006-02-16 17:41 ` Dave Hansen
2006-02-16 19:12 ` Herbert Poetzl
2006-02-16 19:38 ` Dave Hansen
2006-02-16 21:11 ` Sam Vilain
2006-02-20 10:10 ` Kirill Korotaev
2006-02-20 9:50 ` Kirill Korotaev [this message]
2006-02-20 13:00 ` Herbert Poetzl
2006-02-20 14:44 ` Kirill Korotaev
2006-02-20 15:36 ` Herbert Poetzl
2006-02-20 9:13 ` Kirill Korotaev
2006-02-20 18:07 ` Dave Hansen
2006-02-15 23:24 ` Sam Vilain
2006-02-16 5:50 ` Eric W. Biederman
2006-02-20 9:17 ` Kirill Korotaev
2006-02-20 20:01 ` Sam Vilain
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=43F990CA.5080102@sw.ru \
--to=dev@sw.ru \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=benh@kernel.crashing.org \
--cc=clg@fr.ibm.com \
--cc=dev@openvz.org \
--cc=ebiederm@xmission.com \
--cc=frankeh@watson.ibm.com \
--cc=gkurz@fr.ibm.com \
--cc=greg@kroah.com \
--cc=haveblue@us.ibm.com \
--cc=herbert@13thfloor.at \
--cc=jes@sgi.com \
--cc=jgarzik@pobox.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
--cc=riel@redhat.com \
--cc=saw@sawoct.com \
--cc=serue@us.ibm.com \
--cc=ssouhlal@FreeBSD.org \
--cc=torvalds@osdl.org \
--cc=trond.myklebust@fys.uio.no \
--cc=vserver@list.linux-vserver.org \
/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