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(¤t->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
-
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/
This archive was generated by hypermail 2b29 : Thu May 23 2002 - 22:00:12 EST