• NeilBrown's avatar
    fs/seq_file.c: simplify seq_file iteration code and interface · 1f4aace6
    NeilBrown authored
    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: 's avatarNeilBrown <neilb@suse.com>
    Acked-by: Jonathan Corbet <corbet@lwn.net>	[docs]
    Tested-by: 's avatarJann Horn <jannh@google.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Kees Cook <keescook@chromium.org>
    Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
    1f4aace6
seq_file.c 24.4 KB