mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: eligible_child() && __WCLONE && task_detached() (Was: mmotm 2009-08-24-16-24 uploaded)
Date: Fri, 28 Aug 2009 12:16:24 -0700 (PDT)	[thread overview]
Message-ID: <20090828191624.0F5BC45B02@magilla.sf.frob.com> (raw)
In-Reply-To: Oleg Nesterov's message of  Friday, 28 August 2009 19:17:24 +0200 <20090828171724.GA17445@redhat.com>

> eligible_child:
> 
> 	/* Wait for all children (clone and not) if __WALL is set;
> 	 * otherwise, wait for clone children *only* if __WCLONE is
> 	 * set; otherwise, wait for non-clone children *only*.  (Note:
> 	 * A "clone" child here is one that reports to its parent
> 	 * using a signal other than SIGCHLD.) */
> 
> 	if (((p->exit_signal != SIGCHLD) ^ !!(wo->wo_flags & __WCLONE))
> 	    && !(wo->wo_flags & __WALL))
> 		return 0;
> 
> I just can't understand what is the supposed behaviour when p is
> sub-thread and p->exit_signal == -1.

As you say, you're not even supposed to be here when exit_signal = -1,
except for the ptrace case.  This logic exists for the non-CLONE_THREAD
clone case, i.e. ->exit_signal != SIGCHLD and != -1.

> IOW, perhaps this check should be
> 
> 	if (!task_detached(p) && !(wo->wo_flags & __WALL) &&
> 	    (p->exit_signal != SIGCHLD) ^ !!(wo->wo_flags & __WCLONE))
> 		return 0;

That seems OK to me.

> When task_detached(p) == T, "p->exit_signal != SIGCHLD" looks like a
> false positive to me. Because -1 is not a siganl, this is a marker
> which indicates the deatached task - sub-thread or EXIT_DEAD. It _seems_
> to me this check was added when threads were processes, and it was
> possible to wait/reap a thread, not process.

That's all still possible, it's just no longer common.
i.e. clone(SIGUSR1|CLONE_VM, ...) or whatnot (no CLONE_THREAD).

> In short. If ptracer calls wait4(ptraced_sub_thread), is it really
> supposed it must use __WCLONE || __WALL?

I suspect not, but I'm not quite sure.  That is, it makes sense to me that
a ptracer should always get its tracees in all waits.  That is consistent
with not having to use WUNTRACED, for example.  But I'm not really sure any
more what the historical behavior of this has been.  The code in GDB uses
__WALL and __WCLONE in various places, clearly assuming that just ptrace
alone is not enough for every wait4 call to catch every tracee.  It seems
likely that this method was necessary in the past and that's why the code
is like that.


Thanks,
Roland

  reply	other threads:[~2009-08-28 19:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-24 23:28 mmotm 2009-08-24-16-24 uploaded akpm
2009-08-25 10:02 ` KAMEZAWA Hiroyuki
2009-08-26  4:52   ` Amerigo Wang
2009-08-26  6:54     ` KAMEZAWA Hiroyuki
2009-08-26  3:15 ` KAMEZAWA Hiroyuki
2009-08-26  3:36   ` Andrew Morton
2009-08-26  3:44     ` KAMEZAWA Hiroyuki
2009-08-27  5:44 ` KAMEZAWA Hiroyuki
2009-08-27  6:17   ` Hiroshi Shimamoto
2009-08-27  6:31     ` KAMEZAWA Hiroyuki
2009-08-27  7:05   ` KAMEZAWA Hiroyuki
2009-08-27  9:34     ` Oleg Nesterov
2009-08-27  9:43       ` KAMEZAWA Hiroyuki
2009-08-27 10:08         ` Oleg Nesterov
2009-08-27 10:31           ` KAMEZAWA Hiroyuki
2009-08-27 10:52             ` Oleg Nesterov
2009-08-28 17:17               ` eligible_child() && __WCLONE && task_detached() (Was: mmotm 2009-08-24-16-24 uploaded) Oleg Nesterov
2009-08-28 19:16                 ` Roland McGrath [this message]
2009-09-01 12:22                   ` [PATCH -mm 0/2] fix do_wait(!__WALL) hang " Oleg Nesterov
2009-09-01 12:23                     ` [PATCH -mm 1/2] do_wait-wakeup-optimization: fix child_wait_callback()->eligible_child() usage Oleg Nesterov
2009-09-10  0:36                       ` KAMEZAWA Hiroyuki
2009-09-01 12:24                     ` [PATCH -mm 2/2] do_wait-wakeup-optimization: simplify task_pid_type() Oleg Nesterov
2009-08-27 10:17         ` mmotm 2009-08-24-16-24 uploaded KAMEZAWA Hiroyuki
2009-08-27  9:37     ` KAMEZAWA Hiroyuki

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=20090828191624.0F5BC45B02@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --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

all inboxes | Powered by JetHome®