From: Dinakar Guniguntala <dino@in.ibm.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Sripathi Kodi <sripathik@in.ibm.com>,
linux-kernel@vger.kernel.org, Roland McGrath <roland@redhat.com>,
Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] do_wait fix for 2.6.10-rc1
Date: Wed, 10 Nov 2004 20:05:18 +0530 [thread overview]
Message-ID: <20041110143518.GC4502@in.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0411090745250.2301@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]
On Tue, Nov 09, 2004 at 08:11:41AM -0800, Linus Torvalds wrote:
>
> I think I have a potentially better approach: make the rules for "flag" a
> bit more explicit, and make it have structure. We use "flag" for two
> things: we use it to determine if we should return -ECHILD (no children),
> and for whether we should wait for something that might become available
> later. So just split up "flag" into these two meanings, instead of just
> trying to use a single bit:
>
> - one bit that says "we found a child that _will_ wake us up when it's
> ready". In other words, that's a child that is ours, and is not yet a
> zombie.
>
> - one bit that says "we found a child that is ours".
>
> Make "eligible_child()" follow these rules, and then instead of just
> setting "flag = 1", we'd set "flag |= ret".
>
> Now, with these rules, we know just what to do: we only do the wait if the
> "we have children that will wake us up" bit is set. But we return ECHILD
> only if flag is totally clear.
>
> Does that sound like it would fix the problem?
>
How about if we set the flag only in the cases when the exit state is not
either TASK_DEAD or TASK_ZOMBIE.
Patch attached below. I confirmed that this fixes the problem and I also ran
some LTP tests
Signed-off-by: Dinakar Guniguntala <dino@in.ibm.com>
Signed-off-by: Sripathi Kodi <sripathik@in.ibm.com>
[-- Attachment #2: do_wait.patch --]
[-- Type: text/plain, Size: 751 bytes --]
diff -Naurp linux-2.6.10-rc1.orig/kernel/exit.c linux-2.6.10-rc1/kernel/exit.c
--- linux-2.6.10-rc1.orig/kernel/exit.c 2004-10-23 03:10:06.000000000 +0530
+++ linux-2.6.10-rc1/kernel/exit.c 2004-11-10 17:18:20.818103584 +0530
@@ -1325,14 +1325,15 @@ repeat:
ret = eligible_child(pid, options, p);
if (!ret)
continue;
- flag = 1;
switch (p->state) {
case TASK_TRACED:
+ flag = 1;
if (!my_ptrace_child(p))
continue;
/*FALLTHROUGH*/
case TASK_STOPPED:
+ flag = 1;
if (!(options & WUNTRACED) &&
!my_ptrace_child(p))
continue;
@@ -1365,6 +1366,7 @@ repeat:
goto end;
break;
}
+ flag = 1;
check_continued:
if (!unlikely(options & WCONTINUED))
continue;
next prev parent reply other threads:[~2004-11-10 14:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-05 9:57 [PATCH] do_wait fix for 2.6.10-rc1 Sripathi Kodi
2004-11-05 10:03 ` Ingo Molnar
[not found] ` <Pine.LNX.4.58.0411051101500.30457@ppc970.osdl.org>
2004-11-08 14:27 ` Sripathi Kodi
2004-11-08 16:01 ` Linus Torvalds
2004-11-08 16:13 ` Linus Torvalds
2004-11-08 16:37 ` Linus Torvalds
2004-11-09 1:09 ` Linus Torvalds
2004-11-09 14:31 ` Dinakar Guniguntala
2004-11-09 16:11 ` Linus Torvalds
2004-11-10 14:35 ` Dinakar Guniguntala [this message]
2004-11-10 17:04 ` Linus Torvalds
2004-11-11 11:20 ` Sripathi Kodi
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=20041110143518.GC4502@in.ibm.com \
--to=dino@in.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=sripathik@in.ibm.com \
--cc=torvalds@osdl.org \
/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.