1. 02 May, 2016 30 commits
  2. 30 Apr, 2016 1 commit
    • Al Viro's avatar
      atomic_open(): fix the handling of create_error · 10c64cea
      Al Viro authored
      * if we have a hashed negative dentry and either CREAT|EXCL on
      r/o filesystem, or CREAT|TRUNC on r/o filesystem, or CREAT|EXCL
      with failing may_o_create(), we should fail with EROFS or the
      error may_o_create() has returned, but not ENOENT.  Which is what
      the current code ends up returning.
      
      * if we have CREAT|TRUNC hitting a regular file on a read-only
      filesystem, we can't fail with EROFS here.  At the very least,
      not until we'd done follow_managed() - we might have a writable
      file (or a device, for that matter) bound on top of that one.
      Moreover, the code downstream will see that O_TRUNC and attempt
      to grab the write access (*after* following possible mount), so
      if we really should fail with EROFS, it will happen.  No need
      to do that inside atomic_open().
      
      The real logics is much simpler than what the current code is
      trying to do - if we decided to go for simple lookup, ended
      up with a negative dentry *and* had create_error set, fail with
      create_error.  No matter whether we'd got that negative dentry
      from lookup_real() or had found it in dcache.
      
      Cc: stable@vger.kernel.org # v3.6+
      Acked-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      10c64cea
  3. 11 Apr, 2016 6 commits
  4. 10 Apr, 2016 3 commits
    • Linus Torvalds's avatar
      Revert "ext4: allow readdir()'s of large empty directories to be interrupted" · 9f2394c9
      Linus Torvalds authored
      This reverts commit 1028b55b.
      
      It's broken: it makes ext4 return an error at an invalid point, causing
      the readdir wrappers to write the the position of the last successful
      directory entry into the position field, which means that the next
      readdir will now return that last successful entry _again_.
      
      You can only return fatal errors (that terminate the readdir directory
      walk) from within the filesystem readdir functions, the "normal" errors
      (that happen when the readdir buffer fills up, for example) happen in
      the iterorator where we know the position of the actual failing entry.
      
      I do have a very different patch that does the "signal_pending()"
      handling inside the iterator function where it is allowable, but while
      that one passes all the sanity checks, I screwed up something like four
      times while emailing it out, so I'm not going to commit it today.
      
      So my track record is not good enough, and the stars will have to align
      better before that one gets committed.  And it would be good to get some
      review too, of course, since celestial alignments are always an iffy
      debugging model.
      
      IOW, let's just revert the commit that caused the problem for now.
      Reported-by: default avatarGreg Thelen <gthelen@google.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9f2394c9
    • Al Viro's avatar
      reiserfs: switch to generic_{get,set,remove}xattr() · 79a628d1
      Al Viro authored
      reiserfs_xattr_[sg]et() will fail with -EOPNOTSUPP for V1 inodes anyway,
      and all reiserfs instances of ->[sg]et() call it and so does ->set_acl().
      
      Checks for name length in the instances had been bogus; they should've
      been "bugger off if it's _exactly_ the prefix" (as generic would
      do on its own) and not "bugger off if it's shorter than the prefix" -
      that can't happen.
      
      xattr_full_name() is needed to adjust for the fact that generic instances
      will skip the prefix in the name passed to ->[gs]et(); reiserfs homegrown
      analogues didn't.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      79a628d1
    • Al Viro's avatar
      cifs: kill more bogus checks in ->...xattr() methods · 5fdccfef
      Al Viro authored
      none of that stuff can ever be called for NULL or negative
      dentry.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      5fdccfef