(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]>
--- 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;
}
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
* Oleg Nesterov <[email protected]> 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 <[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
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.
On 08/22, Ingo Molnar wrote:
>
> * Oleg Nesterov <[email protected]> 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 <[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.
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
* Oleg Nesterov <[email protected]> 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