Re: /proc dcache deadlock in do_exit

[Eric W. Biederman]

Andrea Arcangeli <andrea@xxxxxxx> writes:

>> 
>> So you may need to apply this one too (this one is needed to fix the
>> second bug, my previous patch is needed after applying this one):
>
> thinking what happened once already, I think this would be more
> debuggable but maybe not... dunno.

Please god no.   The inability to schedule is a bug that apparently
was fixed after sles9 forked off.

In mainline it is safe to sleep until the very end of do_exit and
your suggest patch breaks that.

None of your patches are necessary for mainline.



I believe the commit below is the one that really fixed this issue,
although it may have been something earlier.  But it may have been
earlier, and there have been some significant clean ups since then.

> commit 00732b345b940de766fefaf1297ce26a67bdcea9
> Author: mingo <mingo>
> Date:   Tue Oct 19 06:12:06 2004 +0000
> 
>     [PATCH] fix & clean up zombie/dead task handling & preemption
>     
>     This patch fixes all the preempt-after-task->state-is-TASK_DEAD problems we
>     had.  Right now, the moment procfs does a down() that sleeps in
>     proc_pid_flush() [it could] our TASK_DEAD state is zapped and we might be
>     back to TASK_RUNNING to and we trigger this assert:
>     
>             schedule();
>             BUG();
>             /* Avoid "noreturn function does return".  */
>             for (;;) ;
>     
>     I have split out TASK_ZOMBIE and TASK_DEAD into a separate p->exit_state
>     field, to allow the detaching of exit-signal/parent/wait-handling from
>     descheduling a dead task.  Dead-task freeing is done via PF_DEAD.
>     
>     Tested the patch on x86 SMP and UP, but all architectures should work
>     fine.
>     
>     Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
>     Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
>     Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>
>     
>     BKrev: 4174b036IkpU2-XeLFkjqH681u4Pyg
> 

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/