Messages in this thread | | | Date | Wed, 14 May 2003 08:06:53 -0700 | From | William Lee Irwin III <> | Subject | Re: Race between vmtruncate and mapped areas? |
| |
On Tuesday, May 13, 2003 18:10:18 -0700 Andrew Morton <akpm@digeo.com> wrote: >> That's the one. Process is sleeping on I/O in filemap_nopage(), wakes up >> after the truncate has done its thing and the page gets instantiated in >> pagetables. >> But it's an anon page now. So the application (which was racy anyway) >> gets itself an anonymous page.
On Wed, May 14, 2003 at 10:02:10AM -0500, Dave McCracken wrote: > Which the application thinks is still part of the file, and will expect its > changes to be written back. Granted, if the page fault occurred just after > the truncate it'd get SIGBUS, so it's clearly not a robust assumption, but > it will result in unexpected behavior. Note that if the application later > extends the file to include this page it could result in a corrupted file, > since all the pages around it will be written properly.
Well, for this one I'd say the app loses; it was its own failure to synchronize truncation vs. access, at least given that the kernel doesn't oops.
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |