Messages in this thread | | | Date | Fri, 29 Sep 2000 17:46:17 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: 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(¤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/
| |