From: Oleg Nesterov <oleg@redhat.com>
To: Stas Sergeev <stsp@aknet.ru>
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [path][rfc] add PR_DETACH prctl command
Date: Thu, 31 Mar 2011 19:02:44 +0200 [thread overview]
Message-ID: <20110331170244.GA13271@redhat.com> (raw)
In-Reply-To: <4D94A788.1050806@aknet.ru>
Hi Stas,
On 03/31, Stas Sergeev wrote:
>
> I found some time to get back to that patch and
> to address all of the problems you pointed.
> What do you think about the attached patch?
> I didn't expect it would became that big.
fs/proc/array.c | 7 -
include/asm-generic/siginfo.h | 3
include/linux/init_task.h | 2
include/linux/prctl.h | 2
include/linux/sched.h | 21 +++-
kernel/exit.c | 200 +++++++++++++++++++++++++++++++++++-------
kernel/fork.c | 4
kernel/signal.c | 59 +++++++-----
kernel/sys.c | 45 +++++++++
9 files changed, 281 insertions(+), 62 deletions(-)
Eek! Not only it is big. It is complex and changes a lot of core
kernel code.
Sorry Stas, I am not going to try to review it carefully. As I said,
you need to convince lkml we need this feature first. And iirc you
are not going to suggest this change for everyone.
I guess, the main complication is that you are trying to ensure the
old parent can do wait() without -ECHLD... This complicates everything
soooooooooo much. I _feel_ this can be simplified.... but in any case
we need the nasty complications. And for what?
I only looked at sys_prctl() code, and almost every line looks wrong.
Hmm... in fact, the changes in exit.c look wrong too, but I didn't really
try to understand them.
> @@ -1736,6 +1737,50 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
> else
> error = PR_MCE_KILL_DEFAULT;
> break;
> + case PR_DETACH: {
> + struct task_struct *p, *old_parent;
> + int notif = DEATH_REAP;
> + error = -EPERM;
> + /* not detaching from init */
> + if (me->real_parent == init_pid_ns.child_reaper)
2 problems. You shouldn't use init_pid_ns, you need the task's namespace.
Also, the task can be the child of /sbin/init's sub-thread.
> + write_lock_irq(&tasklist_lock);
> + old_parent = me->real_parent;
> + me->detach_code = arg2 << 8;
> + if (!task_detached(me))
> + notif = do_signal_parent(me, me->exit_signal,
> + CLD_DETACHED, arg2);
This is simply wrong. We reparent the whole thread group, we should
always notify the old parent. Or never. but this shouldn't depend on
the thread.
> + if (notif != DEATH_REAP) {
> + list_add_tail(&me->detached_sibling,
> + &me->real_parent->detached_children);
> + me->exit_state = EXIT_DETACHED;
No, no, we can't set ->exit_state != 0. This means the task is dead.
> + if (!ptrace_reparented(me))
> + me->parent = init_pid_ns.child_reaper;
Again, this shouldn't use init_pid_ns.child_reaper. But the main problem,
you can't trust ptrace_reparented(). What if the old parent ptraces this
task?
> + /* detaching makes us a group leader */
> + me->group_leader = me;
How? Now, we can't change ->group_leader, this is simply not possible
and very wrong. If nothing else, think about tid/tgid, but there are
a lot more problems.
> + while_each_thread(me, p) {
> + if (p->real_parent != old_parent)
> + continue;
> + if (!ptrace_reparented(p))
> + p->parent = init_pid_ns.child_reaper;
> + p->real_parent = init_pid_ns.child_reaper;
The same problems as above, pluse "p->real_parent != old_parent" looks
bogus.
Well. Once again, I never argue with new features, but you need to
convince lkml. Probably it is simple to implement PR_DETACH so that
the task just "disappears" from the old_parent's radar. Otherwise
we need more complications, but I'd rather add the fake TASK_ZOMBIE
task_struct for that. This will be much, much simply although not
pretty anyway.
Oleg.
next prev parent reply other threads:[~2011-03-31 17:03 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 13:50 [path][rfc] add PR_DETACH prctl command Stas Sergeev
2011-02-23 19:14 ` Oleg Nesterov
2011-02-23 20:35 ` Stas Sergeev
2011-02-24 13:29 ` Oleg Nesterov
2011-02-24 15:13 ` Stas Sergeev
2011-02-24 15:32 ` Oleg Nesterov
2011-03-31 16:10 ` Stas Sergeev
2011-03-31 17:02 ` Oleg Nesterov [this message]
2011-03-31 17:47 ` Stas Sergeev
2011-03-31 18:18 ` Oleg Nesterov
2011-03-31 20:58 ` Stas Sergeev
2011-04-02 13:55 ` Oleg Nesterov
2011-04-02 18:20 ` Stas Sergeev
2011-04-02 22:00 ` Stas Sergeev
2011-04-01 17:02 ` Stas Sergeev
2011-04-02 14:06 ` Oleg Nesterov
2011-04-04 14:34 ` Stas Sergeev
2011-04-04 16:03 ` Oleg Nesterov
2011-04-04 20:05 ` Stas Sergeev
2011-04-05 15:15 ` Oleg Nesterov
2011-04-05 16:25 ` Stas Sergeev
2011-04-05 16:45 ` Oleg Nesterov
2011-04-05 17:51 ` Stas Sergeev
2011-04-08 10:51 ` Stas Sergeev
2011-04-08 18:55 ` Oleg Nesterov
2011-04-08 20:16 ` Stas Sergeev
2011-04-11 11:15 ` Stas Sergeev
2011-04-19 14:44 ` [path][rfc] add PR_DETACH prctl command [1/3] Stas Sergeev
2011-04-19 14:50 ` [path][rfc] add PR_DETACH prctl command [2/3] Stas Sergeev
2011-04-19 14:54 ` [path][rfc] add PR_DETACH prctl command [3/3] Stas Sergeev
2011-04-19 14:58 ` Alan Cox
2011-04-19 15:08 ` Stas Sergeev
2011-04-19 15:54 ` Alan Cox
2011-04-19 16:13 ` Oleg Nesterov
2011-04-19 16:29 ` Oleg Nesterov
2011-04-19 16:54 ` Stas Sergeev
2011-04-19 17:20 ` Oleg Nesterov
2011-04-19 17:41 ` Stas Sergeev
2011-04-19 18:17 ` Oleg Nesterov
2011-04-19 16:19 ` Stas Sergeev
2011-04-20 13:12 ` [path][rfc] add PR_DETACH prctl command [1/2] Stas Sergeev
2011-04-20 13:14 ` [path][rfc] add PR_DETACH prctl command [2/2] Stas Sergeev
2011-04-20 16:50 ` Oleg Nesterov
2011-04-20 18:45 ` Stas Sergeev
2011-04-20 19:33 ` Oleg Nesterov
2011-04-20 20:35 ` Stas Sergeev
2011-04-21 20:00 ` Oleg Nesterov
2011-04-21 20:11 ` Stas Sergeev
2011-04-21 10:02 ` Stas Sergeev
2011-04-21 20:15 ` Oleg Nesterov
2011-04-21 20:32 ` Stas Sergeev
2011-04-08 18:13 ` [path][rfc] add PR_DETACH prctl command Bryan Donlan
2011-04-08 20:26 ` Stas Sergeev
2011-04-08 20:52 ` Bryan Donlan
2011-04-08 21:14 ` Stas Sergeev
2011-04-08 21:25 ` Bryan Donlan
2011-04-08 21:38 ` Stas Sergeev
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=20110331170244.GA13271@redhat.com \
--to=oleg@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stsp@aknet.ru \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.