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(¤t->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/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:25 EST