From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Roland McGrath <roland@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH -mm 0/2] fix do_wait(!__WALL) hang (Was: mmotm 2009-08-24-16-24 uploaded)
Date: Tue, 1 Sep 2009 14:22:40 +0200 [thread overview]
Message-ID: <20090901122240.GA20989@redhat.com> (raw)
In-Reply-To: <20090828191624.0F5BC45B02@magilla.sf.frob.com>
On 08/28, Roland McGrath wrote:
>
> > 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.
And this looks more right...
> > 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.
Yes. Let's not change this code. This is user-visible, might break something.
I think it is better to make more "safe" fix.
Oleg.
next prev parent reply other threads:[~2009-09-01 12:26 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
2009-09-01 12:22 ` Oleg Nesterov [this message]
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=20090901122240.GA20989@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@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 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.