Messages in this thread | | | From | Mark Gross <> | Subject | Re: PATCH Multithreaded core dump support for the 2.5.14 (and 15) kernel. | Date | Thu, 16 May 2002 10:13:40 -0400 |
| |
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/
| |