From: Stas Sergeev <stsp@aknet.ru>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [path][rfc] add PR_DETACH prctl command
Date: Thu, 31 Mar 2011 21:47:05 +0400 [thread overview]
Message-ID: <4D94BE19.7050001@aknet.ru> (raw)
In-Reply-To: <20110331170244.GA13271@redhat.com>
31.03.2011 21:02, Oleg Nesterov wrote:
> I only looked at sys_prctl() code, and almost every line looks wrong.
Well, the lines you pointed, were also in the
previous patch, and, as you didn't complained
back then, I thought they were fine. :)
>> + 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.
Does this really break things? I mean, there are
probably no checks like "if (task->exit_state)", every
time the exact value is checked. And EXIT_DETACHED
is only set for the short period: the wait() from parent
(either new or old) will remove it.
>> + /* 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.
OK, thats why in the previous patch I was allowing only
the group leader to detach, but you complained. Should
I return that back?
>> + 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.
Just an extra care. Should I just remove that check?
> 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.
Yes, that worked for me too:
https://lkml.org/lkml/2010/12/25/37
Yes, I know there are bugs too. :) But, at least the patch
is just few lines.
> 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.
Well, maybe the patch looks more complex than it actually is.
How it works:
- num_waiters is set to 1 by fork(). Then PR_DETACH may increment
it if the old parent does not ignore the SIGCHLD. Both the
wait_task_zombie() and wait_task_detached() do decrement that
counter, and when it is zero, the task is reaped. Also, if the old
parent terminates without wait(), it decrements that counter, and,
if needed, reaps the task.
- exit_state is set to EXIT_DETACHED if the parent doesn't ignore
SIGCHLD. Then, if old parent wait()s, exit_state gets reset to 0. But
if the process exits, exit_state gets set to EXIT_ZOMBIE, and then,
by the use of the num_waiters counter, I make sure both parents
waited, before releasing the task.
There were some rearrangements in the exit.c code, that are
not directly related to the new feature. I can split them to the
separate patches, if that will help.
As for convincing LKML... Well, when the code is right, maybe. :))
next prev parent reply other threads:[~2011-03-31 17:47 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 13:50 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
2011-03-31 17:47 ` Stas Sergeev [this message]
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=4D94BE19.7050001@aknet.ru \
--to=stsp@aknet.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@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
Powered by JetHome