> On Thu, Jul 29, 1999 at 10:05:40AM +0530, Ramakrishna@canine.wipinfo.soft.net wrote:
> >
> > Since all the threads ( processes in Linux, though cloned and sharing same
> > MM ) might be running at the time of core-dump in one of the threads,
> > there is most likely possibility of the MM getting changed by the time
> > the dump file is written. This is so because the other processes do not
> > have any knowledge of one of the threads( cloned processes ) being dumped.
> >
> > Though the context ( registers etc ) at the time of dump for the thread
> > dumping core match the ones at theattime of dump , the data in the dump
> > will not reflect the MM data at that point in time for the above reason.
>
> Probably your threads have some mean of synchronization and do not wildly
> write all over their MM but each thread into some private memory area and
> some shared area synchronized by Semaphores (or whatever).
> So the core for the SIGSEGV thread is likely to contain useful info for
> debugging and we shouold dump it to disk. core-$PID is a good idea, however.
[all comments are for 2.3 - this stuff *will* differ between 2.2 and 2.3]
First of all, mm->count is no more. It's mm->mm_users those days. And
it's atomic_t, not int. Now, *if* you are going to do that - care to hold
mm->mmap_sem while you are dumping, otherwise mmap() from another thread
will tear you apart (as in "oopsable race"). Place to modify is
fs/exec.c::do_coredump() - it does the checks in question and creates the
core. So it's not too much work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/