1. 27 7月, 2007 1 次提交
  2. 21 7月, 2007 1 次提交
  3. 20 7月, 2007 4 次提交
  4. 16 7月, 2007 1 次提交
    • J
      splice: direct splicing updates ppos twice · bcd4f3ac
      Jens Axboe 提交于
      OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> reported that he's noticed
      nfsd read corruption in recent kernels, and did the hard work of
      discovering that it's due to splice updating the file position twice.
      This means that the next operation would start further ahead than it
      should.
      
      nfsd_vfs_read()
          splice_direct_to_actor()
              while(len) {
                  do_splice_to()                     [update sd->pos]
                      -> generic_file_splice_read()  [read from sd->pos]
                  nfsd_direct_splice_actor()
                      -> __splice_from_pipe()        [update sd->pos]
      
      There's nothing wrong with the core splice code, but the direct
      splicing is an addon that calls both input and output paths.
      So it has to take care in locally caching offset so it remains correct.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      bcd4f3ac
  5. 13 7月, 2007 2 次提交
  6. 10 7月, 2007 7 次提交
  7. 15 6月, 2007 3 次提交
  8. 08 6月, 2007 5 次提交
  9. 08 5月, 2007 2 次提交
    • J
      [PATCH] splice: always call into page_cache_readahead() · 86aa5ac5
      Jens Axboe 提交于
      Don't try to guess what the read-ahead logic will do, allow it
      to make its own decisions.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      86aa5ac5
    • F
      [PATCH] splice(): fix interaction with readahead · 9ae9d68c
      Fengguang Wu 提交于
      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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      9ae9d68c
  10. 29 3月, 2007 1 次提交
  11. 27 3月, 2007 3 次提交
    • M
      Export __splice_from_pipe() · 40bee44e
      Mark Fasheh 提交于
      Ocfs2 wants to implement it's own splice write actor so that it can better
      manage cluster / page locks. This lets us re-use the rest of splice write
      while only providing our own code where it's actually important.
      Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      40bee44e
    • N
      2/2 splice: dont readpage · 08c72591
      Nick Piggin 提交于
      Splice does not need to readpage to bring the page uptodate before writing
      to it, because prepare_write will take care of that for us.
      
      Splice is also wrong to SetPageUptodate before the page is actually uptodate.
      This results in the old uninitialised memory leak. This gets fixed as a
      matter of course when removing the readpage logic.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      08c72591
    • N
      1/2 splice: dont steal · 485ddb4b
      Nick Piggin 提交于
      Stealing pages with splice is problematic because we cannot just insert
      an uptodate page into the pagecache and hope the filesystem can take care
      of it later.
      
      We also cannot just ClearPageUptodate, then hope prepare_write does not
      write anything into the page, because I don't think prepare_write gives
      that guarantee.
      
      Remove support for SPLICE_F_MOVE for now. If we really want to bring it
      back, we might be able to do so with a the new filesystem buffered write
      aops APIs I'm working on. If we really don't want to bring it back, then
      we should decide that sooner rather than later, and remove the flag and
      all the stealing infrastructure before anybody starts using it.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      485ddb4b
  12. 14 12月, 2006 1 次提交
  13. 09 12月, 2006 1 次提交
  14. 05 11月, 2006 1 次提交
  15. 29 10月, 2006 1 次提交
  16. 20 10月, 2006 3 次提交
  17. 12 10月, 2006 1 次提交
  18. 01 10月, 2006 1 次提交
  19. 10 7月, 2006 1 次提交
    • J
      [PATCH] splice: fix problems with sys_tee() · aadd06e5
      Jens Axboe 提交于
      Several issues noticed/fixed:
      
      - We cannot reliably block in link_pipe() while holding both input and output
        mutexes. So do preparatory checks before locking down both mutexes and doing
        the link.
      
      - The ipipe->nrbufs vs i check was bad, because we could have dropped the
        ipipe lock in-between. This causes us to potentially look at unknown
        buffers if we were racing with someone else reading this pipe.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      aadd06e5