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.
next prev parent 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