futex_find_get_task: remove an obscure EXIT_ZOMBIE check

PATCH In review Oleg Nesterov 3 participants 7 messages Aug 21, 2006 – Aug 25, 2006

lore

Share & tools

lore

Oleg Nesterov

author

2006-08-21 12:42 UTC #0 lore raw

PATCH 1/3 futex_find_get_task: remove an obscure EXIT_ZOMBIE check

(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 <[email protected]>

kernel/futex.c renamed from kernel/futex.c~1_zomb +1 -1

@@ -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;
 	}

Bill Huey (hui)

2006-08-22 00:01 UTC #1 lore raw

Quoted 7 lines · Oleg Nesterov

(Compile tested).
futex_find_get_task:
	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;

Quoted 6 lines

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

Ingo Molnar

Acked-by on v1 1/3

2006-08-22 10:51 UTC #4 lore raw

In reply to Oleg Nesterov

Quoted 7 lines · Oleg Nesterov

(Compile tested).
futex_find_get_task:
	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;

Quoted 8 lines

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 <[email protected]>

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 <[email protected]>

Ingo

Oleg Nesterov

author

2006-08-22 14:10 UTC #2 lore raw

In reply to Bill Huey (hui)

Quoted 16 lines · Bill Huey

Quoted 7 lines · Oleg Nesterov
(Compile tested).
futex_find_get_task:
	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;
Quoted 6 lines
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.

Quoted 2 lines

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.

Oleg Nesterov

author

2006-08-22 14:46 UTC #5 lore raw

In reply to Ingo Molnar

Quoted 17 lines · Ingo Molnar

Quoted 14 lines · 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.

Quoted 5 lines

Quoted 1 line
Signed-off-by Oleg Nesterov <[email protected]>
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.

Bill Huey (hui)

2006-08-22 22:03 UTC #3 lore raw

In reply to Oleg Nesterov

Quoted 19 lines · Oleg Nesterov

Quoted 15 lines · Bill Huey
Quoted 7 lines · Oleg Nesterov
(Compile tested).
futex_find_get_task:
	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
		return NULL;
Quoted 6 lines
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.
Quoted 2 lines
The p->state variable for EXIT_ZOMBIE is only live for some mystery architecture in arch/xtensa/kernel/ptrace.c

Quoted 8 lines

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

# 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;

Ingo Molnar

2006-08-25 10:35 UTC #6 lore raw

In reply to Oleg Nesterov

Quoted 7 lines · Oleg Nesterov

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