1. 13 May, 2016 1 commit
    • Al Viro's avatar
      hfsplus: switch to ->iterate_shared() · 323ee8fc
      Al Viro authored
      We need to protect the list of hfsplus_readdir_data against parallel
      insertions (in readdir) and removals (in release).  Add a spinlock
      for that.  Note that it has nothing to do with protection of
      hfsplus_readdir_data->key - we have an exclusion between hfsplus_readdir()
      and hfsplus_delete_cat() on directory lock and between several
      hfsplus_readdir() for the same struct file on ->f_pos_lock.  The spinlock
      is strictly for list changes.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      323ee8fc
  2. 12 May, 2016 4 commits
  3. 10 May, 2016 4 commits
  4. 09 May, 2016 14 commits
  5. 08 May, 2016 1 commit
    • Al Viro's avatar
      get_rock_ridge_filename(): handle malformed NM entries · 99d82582
      Al Viro authored
      Payloads of NM entries are not supposed to contain NUL.  When we run
      into such, only the part prior to the first NUL goes into the
      concatenation (i.e. the directory entry name being encoded by a bunch
      of NM entries).  We do stop when the amount collected so far + the
      claimed amount in the current NM entry exceed 254.  So far, so good,
      but what we return as the total length is the sum of *claimed*
      sizes, not the actual amount collected.  And that can grow pretty
      large - not unlimited, since you'd need to put CE entries in
      between to be able to get more than the maximum that could be
      contained in one isofs directory entry / continuation chunk and
      we are stop once we'd encountered 32 CEs, but you can get about 8Kb
      easily.  And that's what will be passed to readdir callback as the
      name length.  8Kb __copy_to_user() from a buffer allocated by
      __get_free_page()
      
      Cc: stable@vger.kernel.org # 0.98pl6+ (yes, really)
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      99d82582
  6. 04 May, 2016 1 commit
    • Al Viro's avatar
      ecryptfs: fix handling of directory opening · 6a480a78
      Al Viro authored
      First of all, trying to open them r/w is idiocy; it's guaranteed to fail.
      Moreover, assigning ->f_pos and assuming that everything will work is
      blatantly broken - try that with e.g. tmpfs as underlying layer and watch
      the fireworks.  There may be a non-trivial amount of state associated with
      current IO position, well beyond the numeric offset.  Using the single
      struct file associated with underlying inode is really not a good idea;
      we ought to open one for each ecryptfs directory struct file.
      
      Additionally, file_operations both for directories and non-directories are
      full of pointless methods; non-directories should *not* have ->iterate(),
      directories should not have ->flush(), ->fasync() and ->splice_read().
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      6a480a78
  7. 02 May, 2016 15 commits