lkml.org 
[lkml]   [2000]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Anyone working on multi-threaded core files for 2.4 ?


On Fri, 29 Sep 2000, Alan Cox wrote:

> > > while the dump is taken? How about thread A coredumping, half of the image
> > > being already written and thread B (nowhere near the kernel mode, mind
> > > you) changing the data both in the area that is already dumped and area
> > > the still isn't? After that you can look at the dump and notice absolutely
> > > corrupted data structures - very effective in misdirecting your attempts
> > > to figure out what went wrong.
> >
> > Couldn't all threads be stopped before coredumping begins?
>
> Unless I am missing something doesn't a truncate of a file in parallel also
> yank the pages from under the dump too

Not exactly the same. vmtruncate() doesn't alter the VMA list|AVL-tree, it
just eats the pages, so you get zeroes. mmap() from another thread,
though... We _could_ protect ourselves from that, all right
(down(&current->mm->mmap_sem) and we are OK).

The real problem is different - sure thing, you can get garbled dump if
you truncate one of the mmaped files, but you are virtually guaranteed to
get memory writes from another thread. IOW, it's a difference between "you
can shoot your foot if you want it" and "if you are really lucky you will
not suffer too long".

The question being: is it really worth the trouble? We could try to stop
all threads and get a relatively safe dumps, but that's way trickier than
"remove this silly check and grab ->mmap_sem to avoid oopsen". If somebody
is willing to do that right - sure, why not?

Stopping them all _will_ be tricky - e.g. file creation would better
happen before such attempt, etc. There is a nice deadlock potential, so
we'ld better be very accurate. We should be reasonably safe for a dump on
local fs if we grab the ->mmap_sem and allocate all blocks for dump before
stopping the rest of threads, but frankly, I've no idea what's involved in
NFS and CODA cases.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:45    [W:0.044 / U:1.108 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site