PATCH [PPC64]: dead processes never reaped

From: Linas Vepstas (linas_at_austin.ibm.com)
Date: 04/18/05

  • Next message: Arjan van de Ven: "Re: intercepting syscalls" 
    Date:	Mon, 18 Apr 2005 14:38:33 -0500
To: paulus@samba.org, anton@samba.org

    Hi,

    The patch below appears to fix a problem where a number of dead processes
    linger on the system. On a highly loaded system, dozens of processes
    were found stuck in do_exit(), calling thier very last schedule(), and
    then being lost forever.

    Processes that are PF_DEAD are cleaned up *after* the context switch,
    in a routine called finish_task_switch(task_t *prev). The "prev" gets
    the value returned by _switch() in entry.S, but this value comes from
      
    __switch_to (struct task_struct *prev,
                struct task_struct *new)
    {
       old_thread = &current->thread; ///XXX shouldn't this be prev, not current?
       last = _switch(old_thread, new_thread);
       return last;
    }
     
    The way I see it, "prev" and "current" are almost always going to be
    pointing at the same thing; however, if a "need resched" happens,
    or there's a pre-emept or some-such, then prev and current won't be
    the same; in which case, finish_task_switch() will end up cleaning
    up the old current, instead of prev. This will result in dead processes
    hanging around, which will never be scheduled again, and will never
    get a chance to have put_task_struct() called on them.

    This patch fixes this.

    Signed-off-by: Linas Vepstas <linas@linas.org>

    --- arch/ppc64/kernel/process.c.orig 2005-04-18 14:26:42.000000000 -0500
    +++ arch/ppc64/kernel/process.c 2005-04-18 14:27:54.000000000 -0500
    @@ -204,7 +204,7 @@ struct task_struct *__switch_to(struct t
             flush_tlb_pending();
     
             new_thread = &new->thread;
    - old_thread = &current->thread;
    + old_thread = &prev->thread;
     
             local_irq_save(flags);
             last = _switch(old_thread, new_thread);
    -
    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/

  • Next message: Arjan van de Ven: "Re: intercepting syscalls"

    Relevant Pages

    • Re: PATCH [PPC64]: dead processes never reaped
      ... >> The patch below appears to fix a problem where a number of dead processes ... Naively, we could rturn "prev", this would save a few ... conservative with the patch, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: PATCH [PPC64]: dead processes never reaped
      ... > The patch below appears to fix a problem where a number of dead processes ... don't see any codepath where prev!= current before switch_to. ... switch the entire context, including stack, and thus including the value ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: PATCH [PPC64]: dead processes never reaped
      ... >> The patch below appears to fix a problem where a number of dead processes ... >> linger on the system. ... On a highly loaded system, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: PATCH [PPC64]: dead processes never reaped
      ... >> The patch below appears to fix a problem where a number of dead processes ... All but two of these were Java threads, ... Given that the patch seems to fix the problem, ...
      (Linux-Kernel)
    • Re: PATCH [PPC64]: dead processes never reaped
      ... > The patch below appears to fix a problem where a number of dead processes ... the scheduler itself can be preempted or so ... ... under which circumstances can prev and current be different? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)