summaryrefslogtreecommitdiff
path: root/block
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2007-07-17 04:03:04 -0700
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-07-17 10:22:59 -0700
commita32ea1e1f925399e0d81ca3f7394a44a6dafa12c (patch)
treefade44f4d7baf5695a856ad73e6b98f0d6edf9de /block
parente21ea246bce5bb93dd822de420172ec280aed492 (diff)
Fix read/truncate race
do_generic_mapping_read currently samples the i_size at the start and doesn't do so again unless it needs to call ->readpage to load a page. After ->readpage it has to re-sample i_size as a truncate may have caused that page to be filled with zeros, and the read() call should not see these. However there are other activities that might cause ->readpage to be called on a page between the time that do_generic_mapping_read samples i_size and when it finds that it has an uptodate page. These include at least read-ahead and possibly another thread performing a read. So do_generic_mapping_read must sample i_size *after* it has an uptodate page. Thus the current sampling at the start and after a read can be replaced with a sampling before the copy-out. The same change applied to __generic_file_splice_read. Note that this fixes any race with truncate_complete_page, but does not fix a possible race with truncate_partial_page. If a partial truncate happens after do_generic_mapping_read samples i_size and before the copy_out, the nuls that truncate_partial_page place in the page could be copied out incorrectly. I think the best fix for that is to *not* zero out parts of the page in truncate_partial_page, but rather to zero out the tail of a page when increasing i_size. Signed-off-by: Neil Brown <neilb@suse.de> Cc: Jens Axboe <jens.axboe@oracle.com> Acked-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'block')
0 files changed, 0 insertions, 0 deletions