1. 30 8月, 2018 2 次提交
  2. 23 8月, 2018 1 次提交
  3. 22 8月, 2018 1 次提交
  4. 18 8月, 2018 1 次提交
    • N
      fs/seq_file.c: simplify seq_file iteration code and interface · 1f4aace6
      NeilBrown 提交于
      The documentation for seq_file suggests that it is necessary to be able
      to move the iterator to a given offset, however that is not the case.
      If the iterator is stored in the private data and is stable from one
      read() syscall to the next, it is only necessary to support first/next
      interactions.  Implementing this in a client is a little clumsy.
      
       - if ->start() is given a pos of zero, it should go to start of
         sequence.
      
       - if ->start() is given the name pos that was given to the most recent
         next() or start(), it should restore the iterator to state just
         before that last call
      
       - if ->start is given another number, it should set the iterator one
         beyond the start just before the last ->start or ->next call.
      
      Also, the documentation says that the implementation can interpret the
      pos however it likes (other than zero meaning start), but seq_file
      increments the pos sometimes which does impose on the implementation.
      
      This patch simplifies the interface for first/next iteration and
      simplifies the code, while maintaining complete backward compatability.
      Now:
      
       - if ->start() is given a pos of zero, it should return an iterator
         placed at the start of the sequence
      
       - if ->start() is given a non-zero pos, it should return the iterator
         in the same state it was after the last ->start or ->next.
      
      This is particularly useful for interators which walk the multiple
      chains in a hash table, e.g.  using rhashtable_walk*.  See
      fs/gfs2/glock.c and drivers/staging/lustre/lustre/llite/vvp_dev.c
      
      A large part of achieving this is to *always* call ->next after ->show
      has successfully stored all of an entry in the buffer.  Never just
      increment the index instead.  Also:
      
       - always pass &m->index to ->start() and ->next(), never a temp
         variable
      
       - don't clear ->from when ->count is zero, as ->from is dead when
         ->count is zero.
      
      Some ->next functions do not increment *pos when they return NULL.  To
      maintain compatability with this, we still need to increment m->index in
      one place, if ->next didn't increment it.  Note that such ->next
      functions are buggy and should be fixed.  A simple demonstration is
      
         dd if=/proc/swaps bs=1000 skip=1
      
      Choose any block size larger than the size of /proc/swaps.  This will
      always show the whole last line of /proc/swaps.
      
      This patch doesn't work around buggy next() functions for this case.
      
      [neilb@suse.com: ensure ->from is valid]
        Link: http://lkml.kernel.org/r/87601ryb8a.fsf@notabene.neil.brown.nameSigned-off-by: NNeilBrown <neilb@suse.com>
      Acked-by: Jonathan Corbet <corbet@lwn.net>	[docs]
      Tested-by: NJann Horn <jannh@google.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1f4aace6
  5. 14 8月, 2018 1 次提交
    • C
      f2fs: support fault_type mount option · d494500a
      Chao Yu 提交于
      Previously, once fault injection is on, by default, all kind of faults
      will be injected to f2fs, if we want to trigger single or specified
      combined type during the test, we need to configure sysfs entry, it will
      be a little inconvenient to integrate sysfs configuring into testsuit,
      such as xfstest.
      
      So this patch introduces a new mount option 'fault_type' to assist old
      option 'fault_injection', with these two mount options, we can specify
      any fault rate/type at mount-time.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      d494500a
  6. 08 8月, 2018 2 次提交
  7. 30 7月, 2018 16 次提交
  8. 27 7月, 2018 1 次提交
  9. 23 7月, 2018 2 次提交
  10. 20 7月, 2018 2 次提交
  11. 18 7月, 2018 2 次提交
  12. 12 7月, 2018 2 次提交
  13. 11 7月, 2018 1 次提交
  14. 04 7月, 2018 1 次提交
  15. 29 6月, 2018 1 次提交
    • L
      Revert changes to convert to ->poll_mask() and aio IOCB_CMD_POLL · a11e1d43
      Linus Torvalds 提交于
      The poll() changes were not well thought out, and completely
      unexplained.  They also caused a huge performance regression, because
      "->poll()" was no longer a trivial file operation that just called down
      to the underlying file operations, but instead did at least two indirect
      calls.
      
      Indirect calls are sadly slow now with the Spectre mitigation, but the
      performance problem could at least be largely mitigated by changing the
      "->get_poll_head()" operation to just have a per-file-descriptor pointer
      to the poll head instead.  That gets rid of one of the new indirections.
      
      But that doesn't fix the new complexity that is completely unwarranted
      for the regular case.  The (undocumented) reason for the poll() changes
      was some alleged AIO poll race fixing, but we don't make the common case
      slower and more complex for some uncommon special case, so this all
      really needs way more explanations and most likely a fundamental
      redesign.
      
      [ This revert is a revert of about 30 different commits, not reverted
        individually because that would just be unnecessarily messy  - Linus ]
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a11e1d43
  16. 15 6月, 2018 1 次提交
  17. 08 6月, 2018 2 次提交
  18. 06 6月, 2018 1 次提交