Re: [PATCH 1/2] PF_DEAD: cleanup usage
From: Ingo Molnar (mingo_at_elte.hu)
Date: 11/27/05
- Previous message: Ville Herva: "Re: capturing oopses"
- In reply to: Linus Torvalds: "Re: [PATCH 1/2] PF_DEAD: cleanup usage"
- Next in thread: Ingo Molnar: "Re: [PATCH 1/2] PF_DEAD: cleanup usage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 27 Nov 2005 13:18:35 +0100 To: Linus Torvalds <torvalds@osdl.org>
* Linus Torvalds <torvalds@osdl.org> wrote:
> Well, in all fairness, it's entirely possible (nay, likely) that
> PF_DEAD just isn't relevant the way it used to be.
yes, that's the case. I do believe we should go with Oleg's original
patches.
> Looking at the history, the immediate reason for PF_DEAD was (I think)
> that we had a race where we would first mark the task as a ZOMBIE, and
> then if it was self-reaping, we'd mark it dead in release_task(). But
> we dropped the tasklist_lock in between, which meant that the real
> parent could come in and reap it just before it reaped itself, and all
> hell would break lose.
yeah. Another problem was if we accidentally scheduled somewhere after
the task was marked TASK_DEAD. (That used to be caught by another
PF_DEAD check before the final schedule()).
all this stuff got changed as part of the PREEMPT_VOLUNTARY changes, and
now we exit in a much more robust way.
> HOWEVER. I just noticed something strange. EXIT_DEAD should be in
> "task->exit_state", not in "task->state". So there's something strange
> going on in that neck of the woods _anyway_. That whole
>
> ...
> if (unlikely(prev->flags & PF_DEAD))
> prev->state = EXIT_DEAD;
> ...
>
> in kernel/sched.c seems totally bogus.
no, it's not bogus. PF_DEAD is basically just a fancy, persistent flag
for "mark the task state as EXIT_DEAD atomically before the final
schedule". The TASK_DEAD flag is still necessary so that we dont stay on
the runqueue. [we could use TASK_UNINTERRUPTIBLE - it should just not be
TASK_RUNNING or TASK_INTERRUPTIBLE.]
in any case, i agree with Oleg's patches: with the current code it's
unnecessary to signal towards schedule() to turn the PF_DEAD flag into
EXIT_DEAD - we can do it right where we set PF_DEAD: immediately before
calling the final schedule(). PF_DEAD is a relic from the days when the
exit path was structured differently.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Ville Herva: "Re: capturing oopses"
- In reply to: Linus Torvalds: "Re: [PATCH 1/2] PF_DEAD: cleanup usage"
- Next in thread: Ingo Molnar: "Re: [PATCH 1/2] PF_DEAD: cleanup usage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
