1. 20 9月, 2022 1 次提交
  2. 09 8月, 2022 2 次提交
    • A
      iov_iter: advancing variants of iov_iter_get_pages{,_alloc}() · 1ef255e2
      Al Viro 提交于
      Most of the users immediately follow successful iov_iter_get_pages()
      with advancing by the amount it had returned.
      
      Provide inline wrappers doing that, convert trivial open-coded
      uses of those.
      
      BTW, iov_iter_get_pages() never returns more than it had been asked
      to; such checks in cifs ought to be removed someday...
      Reviewed-by: NJeff Layton <jlayton@kernel.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1ef255e2
    • A
      new iov_iter flavour - ITER_UBUF · fcb14cb1
      Al Viro 提交于
      Equivalent of single-segment iovec.  Initialized by iov_iter_ubuf(),
      checked for by iter_is_ubuf(), otherwise behaves like ITER_IOVEC
      ones.
      
      We are going to expose the things like ->write_iter() et.al. to those
      in subsequent commits.
      
      New predicate (user_backed_iter()) that is true for ITER_IOVEC and
      ITER_UBUF; places like direct-IO handling should use that for
      checking that pages we modify after getting them from iov_iter_get_pages()
      would need to be dirtied.
      
      DO NOT assume that replacing iter_is_iovec() with user_backed_iter()
      will solve all problems - there's code that uses iter_is_iovec() to
      decide how to poke around in iov_iter guts and for that the predicate
      replacement obviously won't suffice.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      fcb14cb1
  3. 15 7月, 2022 1 次提交
  4. 11 6月, 2022 1 次提交
  5. 18 4月, 2022 1 次提交
  6. 08 3月, 2022 1 次提交
  7. 02 2月, 2022 1 次提交
  8. 26 10月, 2021 1 次提交
  9. 18 10月, 2021 1 次提交
  10. 10 4月, 2021 1 次提交
  11. 27 2月, 2021 1 次提交
  12. 25 2月, 2021 1 次提交
  13. 25 1月, 2021 2 次提交
  14. 09 10月, 2020 3 次提交
  15. 07 10月, 2020 1 次提交
  16. 01 7月, 2020 1 次提交
  17. 10 6月, 2020 1 次提交
  18. 28 5月, 2020 1 次提交
  19. 13 5月, 2020 1 次提交
  20. 05 1月, 2020 1 次提交
  21. 01 12月, 2019 1 次提交
  22. 15 10月, 2019 1 次提交
  23. 29 6月, 2019 1 次提交
  24. 21 5月, 2019 1 次提交
  25. 30 4月, 2019 1 次提交
  26. 15 2月, 2019 1 次提交
  27. 22 1月, 2019 1 次提交
  28. 30 11月, 2018 1 次提交
    • M
      fs: fix lost error code in dio_complete · 41e817bc
      Maximilian Heyne 提交于
      commit e2592217 ("fs: simplify the
      generic_write_sync prototype") reworked callers of generic_write_sync(),
      and ended up dropping the error return for the directio path. Prior to
      that commit, in dio_complete(), an error would be bubbled up the stack,
      but after that commit, errors passed on to dio_complete were eaten up.
      
      This was reported on the list earlier, and a fix was proposed in
      https://lore.kernel.org/lkml/20160921141539.GA17898@infradead.org/, but
      never followed up with.  We recently hit this bug in our testing where
      fencing io errors, which were previously erroring out with EIO, were
      being returned as success operations after this commit.
      
      The fix proposed on the list earlier was a little short -- it would have
      still called generic_write_sync() in case `ret` already contained an
      error. This fix ensures generic_write_sync() is only called when there's
      no pending error in the write. Additionally, transferred is replaced
      with ret to bring this code in line with other callers.
      
      Fixes: e2592217 ("fs: simplify the generic_write_sync prototype")
      Reported-by: NRavi Nankani <rnankani@amazon.com>
      Signed-off-by: NMaximilian Heyne <mheyne@amazon.de>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      CC: Torsten Mehlan <tomeh@amazon.de>
      CC: Uwe Dannowski <uwed@amazon.de>
      CC: Amit Shah <aams@amazon.de>
      CC: David Woodhouse <dwmw@amazon.co.uk>
      CC: stable@vger.kernel.org
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      41e817bc
  29. 26 11月, 2018 1 次提交
    • J
      block: make blk_poll() take a parameter on whether to spin or not · 0a1b8b87
      Jens Axboe 提交于
      blk_poll() has always kept spinning until it found an IO. This is
      fine for SYNC polling, since we need to find one request we have
      pending, but in preparation for ASYNC polling it can be beneficial
      to just check if we have any entries available or not.
      
      Existing callers are converted to pass in 'spin == true', to retain
      the old behavior.
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      0a1b8b87
  30. 08 11月, 2018 1 次提交
  31. 24 10月, 2018 1 次提交
  32. 14 5月, 2018 1 次提交
  33. 06 4月, 2018 1 次提交
  34. 13 3月, 2018 2 次提交
  35. 27 2月, 2018 1 次提交
    • J
      direct-io: Fix sleep in atomic due to sync AIO · d9c10e5b
      Jan Kara 提交于
      Commit e864f395 "fs: add RWF_DSYNC aand RWF_SYNC" added additional
      way for direct IO to become synchronous and thus trigger fsync from the
      IO completion handler. Then commit 9830f4be "fs: Use RWF_* flags for
      AIO operations" allowed these flags to be set for AIO as well. However
      that commit forgot to update the condition checking whether the IO
      completion handling should be defered to a workqueue and thus AIO DIO
      with RWF_[D]SYNC set will call fsync() from IRQ context resulting in
      sleep in atomic.
      
      Fix the problem by checking directly iocb flags (the same way as it is
      done in dio_complete()) instead of checking all conditions that could
      lead to IO being synchronous.
      
      CC: Christoph Hellwig <hch@lst.de>
      CC: Goldwyn Rodrigues <rgoldwyn@suse.com>
      CC: stable@vger.kernel.org
      Reported-by: NMark Rutland <mark.rutland@arm.com>
      Tested-by: NMark Rutland <mark.rutland@arm.com>
      Fixes: 9830f4beSigned-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      d9c10e5b