public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Scott James Remnant <scott@canonical.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Roland McGrath <roland@redhat.com>
Subject: Re: [RFC][PATCH] Notify init when processes are reparented to it
Date: Sun, 28 Dec 2008 10:20:24 +0100	[thread overview]
Message-ID: <20081228092024.GA21673@redhat.com> (raw)
In-Reply-To: <20081227114452.GA2919@zelda.netsplit.com>

On 12/27, Scott James Remnant wrote:
>
> Allow the init daemon to be notified by signal when processes are
> reparented to it.  The signal has the same form as SIGCHLD except that
> the si_status field contains the original parent proecss id.

I think the changelog should explain why this change is useful.

I can't judge the usefulness, just a couple of nits about the
code.

> +++ b/include/linux/sched.h
> @@ -1133,6 +1133,7 @@ struct task_struct {
>  	int exit_state;
>  	int exit_code, exit_signal;
>  	int pdeath_signal;  /*  The signal sent when the parent dies  */
> +	int adopt_signal;  /*  The signal sent when a process is reparented  */

Should be cleared in copy_process() ?

And what if init is multithreaded? This should be per-process, not
per-thread.

> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -813,6 +813,9 @@ static void reparent_thread(struct task_struct *p, struct task_struct *father)
>  		/* We already hold the tasklist_lock here.  */
>  		group_send_sig_info(p->pdeath_signal, SEND_SIG_NOINFO, p);
>
> +	if (p->real_parent->adopt_signal)
> +		do_notify_parent_adopted(p, father);
> +

Please note that we notify the new parent even if we re-parent to our
sub-thread, not to the new process. This means that a multithreaded
init can have the false notifications.

And, given that ->adopt_signal is per-thread, a multithreaded init
should be very careful with prctl(PR_SET_ADOPTSIG) if it does not
want to miss the notification.

> +void do_notify_parent_adopted(struct task_struct *tsk, struct task_struct *father)
> +{
> +	struct siginfo info;
> +	unsigned long flags;
> +	struct task_struct *reaper;
> +	struct sighand_struct *sighand;
> +	int ret;
> +
> +	reaper = tsk->real_parent;
> +
> +	memset (&info, 0, sizeof info);

Unneeded? This function seems to fill all interesting fields.

> +	info.si_signo = reaper->adopt_signal;
> +	/*
> +	 * set code to the same range as SIGCHLD so the right bits of
> +	 * siginfo_t get copied, to userspace this will appear as si_code=0
> +	 */
> +	info.si_code = __SI_CHLD;
> +	/*
> +	 * see comment in do_notify_parent() about the following 4 lines
> +	 */
> +	rcu_read_lock();
> +	info.si_pid = task_pid_nr_ns(tsk, reaper->nsproxy->pid_ns);
> +	info.si_status = task_pid_nr_ns(father, reaper->nsproxy->pid_ns);

perhaps it is better to use task_active_pid_ns(reaper).

> +	rcu_read_unlock();
> +
> +	info.si_uid = tsk->uid;
> +
> +	info.si_utime = cputime_to_clock_t(tsk->utime);
> +	info.si_stime = cputime_to_clock_t(tsk->stime);
> +
> +	sighand = reaper->sighand;
> +	spin_lock_irqsave(&sighand->siglock, flags);
> +	__group_send_sig_info(reaper->adopt_signal, &info, reaper);

This looks unsafe.

At this point reaper can already change its ->adopt_signal. For example
if it was cleared, send_signal() can crash while doing (say) sigismember().

Oleg.


  reply	other threads:[~2008-12-28  9:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-27 11:42 [RFC] Notify init when processes are reparented to it Scott James Remnant
2008-12-27 11:44 ` [RFC][PATCH] " Scott James Remnant
2008-12-28  9:20   ` Oleg Nesterov [this message]
2008-12-28 22:01     ` Roland McGrath
2008-12-29 11:50       ` Scott James Remnant
2008-12-29 13:23         ` Oleg Nesterov
2008-12-29 15:21           ` Scott James Remnant
2008-12-29 15:57             ` Oleg Nesterov
2008-12-29 17:36               ` david

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=20081228092024.GA21673@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --cc=scott@canonical.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