public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	lennart@poettering.net, linux-man@vger.kernel.org,
	roland@hack.frob.com, torvalds@linux-foundation.org
Subject: Re: + prctl-add-pr_setget_child_reaper-to-allow-simple-process-supervision .patch added to -mm tree
Date: Wed, 17 Aug 2011 15:45:16 +0200	[thread overview]
Message-ID: <20110817134516.GA14136@redhat.com> (raw)
In-Reply-To: <CAPXgP12rYf2HmmsJAuJw=nrtcjTRR1WzDhLNM47eKhKA1UTfJQ@mail.gmail.com>

On 08/17, Kay Sievers wrote:
>
> On Wed, Aug 17, 2011 at 13:55, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > I try to never argue with the new features. But to be honest, this
> > doesn't look very good to me.
> >
> > OK, a service manager M does prctl(PR_SET_CHILD_REAPER), then it forks
> > a service X which forks another child C and exits. Then C exits and
> > notifies M.
> >
> > But. How can M know that the service X should be restarted? It only
> > knows the pid.
>
> Legacy services write pid files and we read them, so we know the pid
> to watch for. Proper services never double-fork and reparent in a
> modern init environment.

OK. So, this patch can only help to handle the legacy services? And
the service should participate (write pid files for example). And,

>
> > What if wait(WEXITED) succeeds because C in turn does
> > fork + exit?
>
> Nothing is really doing this.

OK. But this means you propose this patch to solve the very specific
problems. IOW, imho this doesn't look very useful "in general" to me.

May be we need something else instead... And iiuc you don't really
need to change the reparenting, you only want the notification if
the process exits.



> >> @@ -1296,6 +1296,8 @@ struct task_struct {
> >>                                * execve */
> >>       unsigned in_iowait:1;
> >>
> >> +     /* Reparent child processes to this process instead of pid 1. */
> >> +     unsigned child_reaper:1;
> >
> > First of all - this is already very wrong imho. This should be
> > per-process, not per-thread.
>
> What do you mean? That would go where instead?

You should mark the whole process as sub-reaper, not a single thread
which does prctl(). The parent/child relationship is process-wide.

If nothing else. Suppose that application does pthread_create(), the
new thread does prctl(REAPER) and exits.

> >> +     /* find the first ancestor which is marked as child_reaper */
> >> +     for (reaper = father->parent;
> >> +          reaper != &init_task && reaper != pid_ns->child_reaper;
> >> +          reaper = reaper->parent)
> >
> > This loop can never reach init_task/child_reaper and crash the kernel.
>
> You mean: *if* this loop can never ...?

Yes.

> > For example, father->parent can point to init_task's sub-thread.
> >
> > OTOH you shouldn't use init_task at all.
>
> What would we use instead?

You should check ->child_reaper only. But see above, it can be multithreaded.

> > Also. You shouldn't do this if the sub-namespace init exits, this is
> > wrong.
>
> It we find a sub-init, before the namespace PID1, why wouldn't we return it?

Ah, I meant pid_ns->child_reaper, not task->child_reaper.

If pid_ns->child_reaper exits we should never try to "reparent" its
children, see zap_pid_ns_processes() in particular. IOW, this should
go into the "else" branch of "if (pid_ns->child_reaper == father)"

Oleg.


  reply	other threads:[~2011-08-17 13:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201108162011.p7GKBcY0023134@imap1.linux-foundation.org>
2011-08-17 11:55 ` + prctl-add-pr_setget_child_reaper-to-allow-simple-process-supervision .patch added to -mm tree Oleg Nesterov
2011-08-17 13:05   ` Oleg Nesterov
2011-08-17 13:21     ` Kay Sievers
2011-08-17 13:37       ` Alan Cox
2011-08-23  0:30         ` Colin Walters
2011-08-17 14:16       ` Oleg Nesterov
2011-08-17 16:03       ` Denys Vlasenko
2011-08-17 13:13   ` Kay Sievers
2011-08-17 13:45     ` Oleg Nesterov [this message]
2011-08-17 15:45       ` Kay Sievers
2011-08-17 15:53         ` Alan Cox
2011-08-17 16:20         ` Oleg Nesterov
2011-08-17 16:47           ` Kay Sievers
2011-08-17 18:57             ` Oleg Nesterov
2011-08-17 20:56               ` Kay Sievers
2011-08-18 12:43       ` Lennart Poettering
2011-08-18 14:25         ` Oleg Nesterov
2011-08-18 18:11           ` Kay Sievers
2011-08-18 18:48             ` Oleg Nesterov
2011-08-19  1:31               ` Kay Sievers
2011-08-19 12:25                 ` Oleg Nesterov
2011-08-19 12:44                   ` Kay Sievers
2011-08-19 13:13                     ` Oleg Nesterov
2011-08-19 14:20                       ` Kay Sievers
2011-08-19 14:58                         ` Oleg Nesterov
2011-08-20 15:33                           ` Oleg Nesterov
2011-08-21 18:33                             ` Kay Sievers
2011-08-22 11:14                               ` Oleg Nesterov
2011-08-22 23:48                                 ` Kay Sievers
2011-08-18 21:23             ` Linus Torvalds
2011-08-18 21:55               ` Kay Sievers
2011-08-18 22:22                 ` Linus Torvalds
2011-08-19  0:48                   ` Kay Sievers

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=20110817134516.GA14136@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kay.sievers@vrfy.org \
    --cc=lennart@poettering.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=roland@hack.frob.com \
    --cc=torvalds@linux-foundation.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