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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox