diff options
author | Fengguang Wu <fengguang.wu@gmail.com> | 2007-05-08 08:44:36 +0200 |
---|---|---|
committer | Jens Axboe <jens.axboe@oracle.com> | 2007-05-08 08:44:36 +0200 |
commit | 9ae9d68cbf3fe0ec17c17c9ecaa2188ffb854a66 (patch) | |
tree | d29b5e56b7c18c06a1a08d6e27c8862205fa2d86 /fs/bfs | |
parent | 5b94f675f57e4ff16c8fda09088d7480a84dcd91 (diff) | |
download | linux-9ae9d68cbf3fe0ec17c17c9ecaa2188ffb854a66.tar.gz linux-9ae9d68cbf3fe0ec17c17c9ecaa2188ffb854a66.tar.bz2 linux-9ae9d68cbf3fe0ec17c17c9ecaa2188ffb854a66.zip |
[PATCH] splice(): fix interaction with readahead
Eric Dumazet, thank you for disclosing this bug.
Readahead logic somehow fails to populate the page range with data.
It can be because
1) the readahead routine is not always called in the following lines of
fs/splice.c:
if (!loff || nr_pages > 1)
page_cache_readahead(mapping, &in->f_ra, in, index, nr_pages);
2) even called, page_cache_readahead() wont guarantee the pages are there.
It wont submit readahead I/O for pages already in the radix tree, or when
(ra_pages == 0), or after 256 cache hits.
In your case, it should be because of the retried reads, which lead to
excessive cache hits, and disables readahead at some time.
And that _one_ failure of readahead blocks the whole read process.
The application receives EAGAIN and retries the read, but
__generic_file_splice_read() refuse to make progress:
- in the previous invocation, it has allocated a blank page and inserted it
into the radix tree, but never has the chance to start I/O for it: the test
of SPLICE_F_NONBLOCK goes before that.
- in the retried invocation, the readahead code will neither get out of the
cache hit mode, nor will it submit I/O for an already existing page.
Cc: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Diffstat (limited to 'fs/bfs')
0 files changed, 0 insertions, 0 deletions