From: "Albert Cahalan" <acahalan@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, jengelh@linux01.gwdg.de,
holt@sgi.com, oleg@tv-sign.ru, roland@redhat.com
Subject: Re: [RFC, PATCH 1/3] introduce SYS_CLONE_MASK
Date: Tue, 29 May 2007 20:33:44 -0400 [thread overview]
Message-ID: <787b0d920705291733t7a2ca052tbad7e11bbe0b1eff@mail.gmail.com> (raw)
In-Reply-To: <m1646c8c33.fsf@ebiederm.dsl.xmission.com>
On 5/29/07, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Albert Cahalan" <acahalan@gmail.com> writes:
> > Jan Engelhardt writes:
>>> - if(self_pid==1 && ADOPTED(processes[i]) && forest_type!='u')
>>> + if(ADOPTED(processes[i]) && forest_type!='u')
>>
>> That's not compatible because init's children are now in the
>> logical place. Since the days of procps-1.x.x or earlier,
>> such processes have been listed at top level.
>>
>> BTW, what does "ps -ejH" do for you, with and without the patch?
>
> ps -ejH displays everything.
That's not what I mean. (the "-e" causes that of course)
I'm asking about the parent-child relationships shown.
The "-H" option is a bit different from the "f" option.
>> I'd be a lot happier about breaking compatibility in this area
>> if I could get a functional adoption flag. That is, I really
>> would like to show a process as child of init if it naturally
>> was created as a child of init. It's less informative to have
>> fake children showing up the same as real ones. The original
>> parent PID would do. (BTW, the original parent name and/or
>> grandparent PID would be great to have) As a bonus, the kernel
>> could reap these processes more quickly than init can... and
>> then maybe we can stop caring if init is alive.
>
> Having the kernel not reparent user processes to init is an interesting
> idea, especially when those processes have not existed. I'm not
> certain that is POSIX complaint and otherwise backwards compatible.
I'm not suggesting that this be visible via POSIX APIs.
It's almost certainly a given that getppid() must return 1, and
probably /proc needs to show this as well. Without question,
any process created by init must be reaped by init.
Processes NOT created by init could be silently reaped by
the kernel. They need to see their own PPID as 1, but there
need not be any parent-child relationship in the kernel data
structures. The kernel can fake the whole thing, which is nice
because then the kernel isn't depending on userspace to
correctly perform the pointless action of playing with zombies.
(might setting the death signal to 0 be useful here?)
For "ps fax" and such, I'd like to distinguish between init's
real and adopted children. Right now the adopted children
look like they were created by init, which is not true. I only
need a simple boolean flag, set upon reparenting, to tell me.
Such a flag may also be useful for optimizing away the whole
wait/waitpid/wait4/waitid/wait3 nonsense when an adopted
child dies.
next prev parent reply other threads:[~2007-05-30 0:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-29 3:23 Albert Cahalan
2007-05-29 4:53 ` Eric W. Biederman
2007-05-29 5:56 ` Roland McGrath
2007-05-30 0:33 ` Albert Cahalan [this message]
2007-05-30 1:43 ` Eric W. Biederman
2007-07-26 7:34 ` Jan Engelhardt
-- strict thread matches above, loose matches on Subject: below --
2007-05-29 2:59 Albert Cahalan
2007-05-29 4:57 ` Eric W. Biederman
2007-04-08 15:53 Oleg Nesterov
2007-04-08 16:19 ` Eric W. Biederman
2007-04-08 16:57 ` Oleg Nesterov
2007-04-09 1:05 ` Eric W. Biederman
2007-04-09 2:06 ` Roland McGrath
2007-04-09 16:20 ` Eric W. Biederman
2007-04-09 17:30 ` Robin Holt
2007-04-10 0:35 ` Eric W. Biederman
2007-04-10 9:56 ` Robin Holt
2007-04-09 9:06 ` Oleg Nesterov
2007-04-09 10:43 ` Robin Holt
2007-04-09 14:36 ` Eric W. Biederman
2007-04-09 14:52 ` Robin Holt
2007-04-10 15:47 ` Jan Engelhardt
2007-04-10 18:20 ` Jan Engelhardt
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=787b0d920705291733t7a2ca052tbad7e11bbe0b1eff@mail.gmail.com \
--to=acahalan@gmail.com \
--cc=ebiederm@xmission.com \
--cc=holt@sgi.com \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=roland@redhat.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
all inboxes | Powered by JetHome®