Re: PATCH Multithreaded core dump support for the 2.5.14 (and 15) kernel.

[Mark Gross <mgross@unix-os.sc.intel.com>]

On Thursday 16 May 2002 08:54 am, Andi Kleen wrote:
> Mark Gross <mgross@unix-os.sc.intel.com> writes:
> > Any driver that holds a lock across any sleep_on call I think is abusing
> > locks and needs adjusting.
>
> That's true for spinlocks, but not for semaphores. The mm layer and the
> vfs layer both use semaphores extensively and sleep with them hold,
> also some other subsystems (like networking) use sleeping locks.
>
> -Andi

Hmmm, then the only nasty bit I see is the down_write(&current->mm->mmap_sem) 
in elf_core_dump.  

If as durring a core dump, one of the suspended thread processes had the 
mmap_sem for the currently dumping process, AND was sleeping, then I could 
get into trouble.  This could happen with thread processes created using the 
CLONE_VM flag (pthread applications use this flag).

I've just spent a bit of time grepping around looking for places a process 
could grab the mmap_sem and then sleep but didn't find anything.   I know 
this doesn't prove anything, but I had to look ;)

Does anyone knowlegible with the use / role of the mm_sem in the kernel have 
any insight into its use that would help me?  I would really like to make the 
TCORE patch work well.

Also, does anyone know WHY the mmap_sem is needed in the elf_core_dump code, 
and is this need still valid if I've suspended all the other processes that 
could even touch that mm?  I.e. can I fix this by removing the down_write / 
up_write in elf_core_dump?

--mgross