Can anyone explain why this test is in routine `do_coredump'
in file `fs/exec.c' in the 2.4.0 kernel?
if (!current->dumpable || atomic_read(¤t->mm->mm_users) != 1)
goto fail;
The only thing the test on `mm_users' seems to be doing is stopping
a thread process from dumping core. What's the rationale for this?
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/938-9838
> Can anyone explain why this test is in routine `do_coredump'
> in file `fs/exec.c' in the 2.4.0 kernel?
>
> if (!current->dumpable || atomic_read(¤t->mm->mm_users) != 1)
> goto fail;
>
> The only thing the test on `mm_users' seems to be doing is stopping
> a thread process from dumping core. What's the rationale for this?
The I/O to dump the core would race other changes on the mm. The right fix
is probably to copy the mm (as fork does) then dump the copy.
On Sat, Feb 24, 2001 at 09:57:44PM +0000, Alan Cox wrote:
The I/O to dump the core would race other changes on the mm. The
right fix is probably to copy the mm (as fork does) then dump the
copy.
Stupid question... but since all threads see the same memory space as
each other; can we not lock the entire vma for the process whilst
it's being written out?
--cw
Theres a patch floating around that does just that. Its an obvious
hack. I would like to see something clean get into the mainstream
kernels. Its a real pain not to have cores for threaded code.
It does work, however. It effectively dumps the thread that caused the
fault.
(I have a complimentary hack that will dump the stacks of all the
rest of the threads as well (though its a good trick to get gdb to
interpret this). Available upon request.)
af
On Sun, 25 Feb 2001, Chris Wedgwood wrote:
> On Sat, Feb 24, 2001 at 09:57:44PM +0000, Alan Cox wrote:
>
> The I/O to dump the core would race other changes on the mm. The
> right fix is probably to copy the mm (as fork does) then dump the
> copy.
>
> Stupid question... but since all threads see the same memory space as
> each other; can we not lock the entire vma for the process whilst
> it's being written out?
>
>
>
> --cw
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Chris Wedgwood <[email protected]> writes:
> On Sat, Feb 24, 2001 at 09:57:44PM +0000, Alan Cox wrote:
>
> The I/O to dump the core would race other changes on the mm. The
> right fix is probably to copy the mm (as fork does) then dump the
> copy.
>
> Stupid question... but since all threads see the same memory space as
> each other; can we not lock the entire vma for the process whilst
> it's being written out?
It would need a recursive mm semaphore -- core dumps can page fault and page
faults take the semaphore again. Other alternative is to copy the MM like
fork before dumping, but then core dumping could fail much quicker when you
ran out of memory.
-Andi
On Sun, Feb 25, 2001 at 11:28:14AM +0100, Andi Kleen wrote:
It would need a recursive mm semaphore -- core dumps can page
fault and page faults take the semaphore again. Other alternative
is to copy the MM like fork before dumping, but then core dumping
could fail much quicker when you ran out of memory.
Ouch... would creating another semaphore or flag 'dumping_core' work
or is that jut a bad idea?
I ask this because like it or not; people use threaded applications
and having threaded core dumps would be cool. Requiring a copy to
dump isn't really elegant or an option if you run a process who's RSS
is 400M on a 512MB machine as I do.
--cw
> On Sat, Feb 24, 2001 at 09:57:44PM +0000, Alan Cox wrote:
>
> The I/O to dump the core would race other changes on the mm. The
> right fix is probably to copy the mm (as fork does) then dump the
> copy.
>
> Stupid question... but since all threads see the same memory space as
> each other; can we not lock the entire vma for the process whilst
> it's being written out?
It isnt the vma, its the entire mm you would need to lock. And I dont think
you can do a deadlock free lock of that sanely, hence its better to copy
the mm (thats pretty efficienty anyway as it wont copy the data)
> It does work, however. It effectively dumps the thread that caused the
> fault.
If you want that behavior, catch SIGSEGV, fork, and have the child
process (in which only the faulting thread exists) call abort.
DS
OK, I followed Alan's suggestion and here is a patch, relative to
the 2.4.1 kernel, that copies the mm and dumps the corefile from
that copy. Also, whenever there are multiple users of the original
mm it creates the core dump in the file `core.n' where `n' is the
PID of the offending process.
I would contend that this fixes a bug and should be put into the
2.4 but if the concensus is that it's a new 2.5 feature that's fine.
On Sat, Feb 24, 2001 at 09:57:44PM +0000, Alan Cox wrote:
> > Can anyone explain why this test is in routine `do_coredump'
> > in file `fs/exec.c' in the 2.4.0 kernel?
> >
> > if (!current->dumpable || atomic_read(¤t->mm->mm_users) != 1)
> > goto fail;
> >
> > The only thing the test on `mm_users' seems to be doing is stopping
> > a thread process from dumping core. What's the rationale for this?
>
> The I/O to dump the core would race other changes on the mm. The right fix
> is probably to copy the mm (as fork does) then dump the copy.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/938-9838
> the 2.4.1 kernel, that copies the mm and dumps the corefile from
> that copy. Also, whenever there are multiple users of the original
> mm it creates the core dump in the file `core.n' where `n' is the
> PID of the offending process.
> + if ((mm = kmem_cache_alloc(mm_cachep, SLAB_KERNEL)) == NULL)
> + goto close_fail;
> + memcpy(mm, current->mm, sizeof(*mm));
> + if (!mm_init(mm)) {
> + kmem_cache_free(mm_cachep, mm);
> + goto close_fail;
> + }
> + down(¤t->mm->mmap_sem);
Umm not quite what I meant. Take a look at copy_mm in fork.c
The code starting
m = allocate_mm()
down to just before
/*
* child gets a
Does the real thing you need to do to be sure the mm is properly set up.
You can also drop the original mm and make that current->mm to avoid the
passing of mm around. In fact you probably should do that.
Umm I misread that patch somewhat. I take that comment back. It does indeed
do what I intended.
Would the mm folks care to verify the patch..
Don,
I've searched the linux-kernel mail archives about this patch, and the most
recent
thing I can find is that it was waiting for verification.
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0102.3/0553.html
Is there anything more recent? Has it been accepted?
Also, if I apply this patch to the kernel I am running (2.4.2), will I need
to patch gdb to be able
to read core dumps made by threads? Or should I ask the gdb maintainers
this question?
Please include my mail address in your response, as I do not subscribe to
linux-kernel.
Thanks,
-John
----------------------------------------------------------------------------
--------------------------------------------
John Van Horne voice: 650-628-4148
Software Tools Engineer fax: 650-637-2411
CoSine Communications, Inc. cell: 650-346-0401
<http://www.cosinecom.com> email:
[email protected]
----------------------------------------------------------------------------
--------------------------------------------