[PATCH 1/3] futex_find_get_task: remove an obscure EXIT_ZOMBIE check

[PATCH 1/3] futex_find_get_task: remove an obscure EXIT_ZOMBIE check

[Oleg Nesterov]

(Compile tested).

futex_find_get_task:

	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;

I can't understand this. First, p->state can't be EXIT_ZOMBIE. The ->exit_state
check looks strange too. Sub-threads or tasks whose ->parent ignores SIGCHLD go
directly to EXIT_DEAD state (I am ignoring a ptrace case). Why EXIT_DEAD tasks
should be ok? Yes, EXIT_ZOMBIE is more important (a task may stay zombie for a
long time), but this doesn't mean we should explicitely ignore other EXIT_XXX
states.

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>

--- 2.6.18-rc4/kernel/futex.c~1_zomb	2006-08-21 18:45:43.000000000 +0400
+++ 2.6.18-rc4/kernel/futex.c	2006-08-21 20:32:48.000000000 +0400
@@ -397,7 +397,7 @@ static struct task_struct * futex_find_g
 		p = NULL;
 		goto out_unlock;
 	}
-	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE) {
+	if (p->exit_state != 0) {
 		p = NULL;
 		goto out_unlock;
 	}

Re: [PATCH 1/3] futex_find_get_task: remove an obscure EXIT_ZOMBIE check

[Bill Huey]

On Mon, Aug 21, 2006 at 09:06:04PM +0400, Oleg Nesterov wrote:
> (Compile tested).
> 
> futex_find_get_task:
> 
> 	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
> 		return NULL;
> 
> I can't understand this. First, p->state can't be EXIT_ZOMBIE. The ->exit_state
> check looks strange too. Sub-threads or tasks whose ->parent ignores SIGCHLD go
> directly to EXIT_DEAD state (I am ignoring a ptrace case). Why EXIT_DEAD tasks
> should be ok? Yes, EXIT_ZOMBIE is more important (a task may stay zombie for a
> long time), but this doesn't mean we should explicitely ignore other EXIT_XXX
> states.

The p->state variable for EXIT_ZOMBIE is only live for some mystery architecture
in arch/xtensa/kernel/ptrace.c

It could be a typo under architecture so maybe it's better fixed there as well
with a "state" to "exit_state" change. I don't really know for sure since I don't
work under that architecure.

bill

Re: [PATCH 1/3] futex_find_get_task: remove an obscure EXIT_ZOMBIE check

[Oleg Nesterov]

On 08/21, Bill Huey wrote:
>
> On Mon, Aug 21, 2006 at 09:06:04PM +0400, Oleg Nesterov wrote:
> > (Compile tested).
> > 
> > futex_find_get_task:
> > 
> > 	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
> > 		return NULL;
> > 
> > I can't understand this. First, p->state can't be EXIT_ZOMBIE. The ->exit_state
> > check looks strange too. Sub-threads or tasks whose ->parent ignores SIGCHLD go
> > directly to EXIT_DEAD state (I am ignoring a ptrace case). Why EXIT_DEAD tasks
> > should be ok? Yes, EXIT_ZOMBIE is more important (a task may stay zombie for a
> > long time), but this doesn't mean we should explicitely ignore other EXIT_XXX
> > states.
> 
> The p->state variable for EXIT_ZOMBIE is only live for some mystery architecture
> in arch/xtensa/kernel/ptrace.c

Thanks. This

	case PTRACE_KILL:
		ret = 0;
		if (child->state == EXIT_ZOMBIE)	/* already dead */
			break;

is an obvious bug, I beleive. May I suggest you to make a patch?

Oleg.

Re: [PATCH 1/3] futex_find_get_task: remove an obscure EXIT_ZOMBIE check

[Bill Huey]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

On Tue, Aug 22, 2006 at 10:34:31PM +0400, Oleg Nesterov wrote:
> On 08/21, Bill Huey wrote:
> > On Mon, Aug 21, 2006 at 09:06:04PM +0400, Oleg Nesterov wrote:
> > > (Compile tested).
> > > 
> > > futex_find_get_task:
> > > 
> > > 	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
> > > 		return NULL;
> > > 
> > > I can't understand this. First, p->state can't be EXIT_ZOMBIE. The ->exit_state
> > > check looks strange too. Sub-threads or tasks whose ->parent ignores SIGCHLD go
> > > directly to EXIT_DEAD state (I am ignoring a ptrace case). Why EXIT_DEAD tasks
> > > should be ok? Yes, EXIT_ZOMBIE is more important (a task may stay zombie for a
> > > long time), but this doesn't mean we should explicitely ignore other EXIT_XXX
> > > states.
> > 
> > The p->state variable for EXIT_ZOMBIE is only live for some mystery architecture
> > in arch/xtensa/kernel/ptrace.c
> 
> Thanks. This
> 
> 	case PTRACE_KILL:
> 		ret = 0;
> 		if (child->state == EXIT_ZOMBIE)	/* already dead */
> 			break;
> 
> is an obvious bug, I beleive. May I suggest you to make a patch?

Oleg,

Here is it. Maintainers CCed...

bill


[-- Attachment #2: t.diff --]
[-- Type: text/plain, Size: 665 bytes --]

# 
# old_revision [d374cc860b7089468eb87b56425bb462a955b138]
# 
# patch "arch/xtensa/kernel/ptrace.c"
#  from [4ae4da59c97b72d41f6d2b38ef83f33ee8e5e3e3]
#    to [6be23f16368960b0da9f77911406e7c495396001]
# 
============================================================
--- arch/xtensa/kernel/ptrace.c	4ae4da59c97b72d41f6d2b38ef83f33ee8e5e3e3
+++ arch/xtensa/kernel/ptrace.c	6be23f16368960b0da9f77911406e7c495396001
@@ -212,7 +212,7 @@
 	 */
 	case PTRACE_KILL:
 		ret = 0;
-		if (child->state == EXIT_ZOMBIE)	/* already dead */
+		if (child->exit_state == EXIT_ZOMBIE)	/* already dead */
 			break;
 		child->exit_code = SIGKILL;
 		child->ptrace &= ~PT_SINGLESTEP;

Re: [PATCH 1/3] futex_find_get_task: remove an obscure EXIT_ZOMBIE check

[Ingo Molnar]

* Oleg Nesterov <oleg@tv-sign.ru> wrote:

> (Compile tested).
> 
> futex_find_get_task:
> 
> 	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
> 		return NULL;
> 
> I can't understand this. First, p->state can't be EXIT_ZOMBIE. The 
> ->exit_state check looks strange too. Sub-threads or tasks whose 
> ->parent ignores SIGCHLD go directly to EXIT_DEAD state (I am ignoring 
> a ptrace case). Why EXIT_DEAD tasks should be ok? Yes, EXIT_ZOMBIE is 
> more important (a task may stay zombie for a long time), but this 
> doesn't mean we should explicitely ignore other EXIT_XXX states.
> 
> Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>

i believe this is a remnant of older times when EXIT_ZOMBIE was 
introduced. We cloned that into the -rt tree, but then exit-state got 
cleaned up (by you) upstream and that cleanup didnt propagate into the 
-rt tree. Andrew: i think this is a must-have fix for v2.6.18.

Acked-by: Ingo Molnar <mingo@elte.hu>

	Ingo

Re: [PATCH 1/3] futex_find_get_task: remove an obscure EXIT_ZOMBIE check

[Oleg Nesterov]

On 08/22, Ingo Molnar wrote:
> 
> * Oleg Nesterov <oleg@tv-sign.ru> wrote:
> 
> > (Compile tested).
> > 
> > futex_find_get_task:
> > 
> > 	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
> > 		return NULL;
> > 
> > I can't understand this. First, p->state can't be EXIT_ZOMBIE. The 
> > ->exit_state check looks strange too. Sub-threads or tasks whose 
> > ->parent ignores SIGCHLD go directly to EXIT_DEAD state (I am ignoring 
> > a ptrace case). Why EXIT_DEAD tasks should be ok? Yes, EXIT_ZOMBIE is 
> > more important (a task may stay zombie for a long time), but this 
> > doesn't mean we should explicitely ignore other EXIT_XXX states.
> > 
> > Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
> 
> i believe this is a remnant of older times when EXIT_ZOMBIE was 
> introduced. We cloned that into the -rt tree, but then exit-state got 
> cleaned up (by you)

No, no, it was Roland.

But probably you are talking about these patches

	http://marc.theaimsgroup.com/?t=113284375800003&r=1
	http://marc.theaimsgroup.com/?t=113284375800005&r=1

? It was abandoned by Linus. It is not clear was he convinced or not,
but I'd be happy to re-send this patch (on weekend) if you wish.

Oleg.

Re: [PATCH 1/3] futex_find_get_task: remove an obscure EXIT_ZOMBIE check

[Ingo Molnar]

* Oleg Nesterov <oleg@tv-sign.ru> wrote:

> But probably you are talking about these patches
> 
> 	http://marc.theaimsgroup.com/?t=113284375800003&r=1
> 	http://marc.theaimsgroup.com/?t=113284375800005&r=1
> 
> ? It was abandoned by Linus. It is not clear was he convinced or not, 
> but I'd be happy to re-send this patch (on weekend) if you wish.

sure, please do. I'm not sure how and why they were dropped - it's the 
author (you) who is supposed to push it! :-) (Sometimes patches can drop 
out of -mm due to logistical clashes or due to bugs - just re-merge / 
fix them in that case.) These patches certainly make alot of sense.

	Ingo