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

Mark Gross
2002-05-16T17:14:11Z

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