On Fri, Feb 09, 2007 at 11:45:39AM -0800, Andrew Morton wrote: > On Fri, 9 Feb 2007 11:14:55 -0800 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > If so, that might be preventable by leaving the buffer nonuptodate. > > oh, OK, it was buffer_new(), so zeroes are the right thing for a reader to > see. > > But if it wasn't buffer_new() then the appropriate thing for the reader to > see is what's on the disk. But __block_prepare_write() won't read a buffer > which is fully-inside the write area from disk. > > And that's seemingly OK, because if a reader gets in there after the short > copy, that reader will see the non-uptodate buffer and will populate it > from disk. > > But doing that will overwrite the data which the write() caller managed to > copy into the page before it took a fault. And that's not OK because > block_perform_write() does iovec_iterator_advance(i, copied) in this case > and hence will not rerun the copy after acquiring the page lock? Hmm, yeah. This can be handled by not advancing partially into a !uptodate buffer. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
