Re: [PATCH] multithreaded coredumps for elf exeecutables

["Vamsi Krishna S ." <vamsi@in.ibm.com>]

Dan,

Thanks for pointing this out. I see that this change has now gone into
2.4.18 as well as 2.5.4. We would ensure that the down_write happens
only after the registers of all threads are collected.

Coming back to the original point raised by Pavel, indeed there is 
nothing preventing external code (any other kernel modules) modifying
the cpus_allowed field from under us. This could get worse in 2.5.x
where a user could change cpu affinity (through proc or a syscall, 
though I don't think the patches providing this are accepted as yet).

Vamsi.

On Wed, Mar 20, 2002 at 01:37:09PM -0500, Daniel Jacobowitz wrote:
> On Wed, Mar 20, 2002 at 11:36:30AM +0530, Vamsi Krishna S . wrote:
> > There is serialization at higher level. We take a write lock
> > on current->mm->mmap_sem at the beginning of elf_core_dump
> > function which is released just before leaving the function.
> > So, if one thread enters elf_core_dump and starts dumping core,
> > no other thread (same mm) of the same process can start
> > dumping.
> > <snip>
> 
> That's not a feature, it's a bug.  You can't take the mmap_sem before
> collecting thread status; it will cause a deadlock on at least ia64,
> where some registers are collected from user memory.
> 
> (Thanks to Manfred Spraul for explaining that to me.)
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

-- 
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5262355 Extn: 3959
Internet: vamsi@in.ibm.com