]> git.baikalelectronics.ru Git - kernel.git/commitdiff
Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
authorLinus Torvalds <torvalds@linux-foundation.org>
Fri, 6 Dec 2019 17:06:58 +0000 (09:06 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 6 Dec 2019 17:06:58 +0000 (09:06 -0800)
Pull vfs d_inode/d_flags memory ordering fixes from Al Viro:
 "Fallout from tree-wide audit for ->d_inode/->d_flags barriers use.
  Basically, the problem is that negative pinned dentries require
  careful treatment - unless ->d_lock is locked or parent is held at
  least shared, another thread can make them positive right under us.

  Most of the uses turned out to be safe - the main surprises as far as
  filesystems are concerned were

   - race in dget_parent() fastpath, that might end up with the caller
     observing the returned dentry _negative_, due to insufficient
     barriers. It is positive in memory, but we could end up seeing the
     wrong value of ->d_inode in CPU cache. Fixed.

   - manual checks that result of lookup_one_len_unlocked() is positive
     (and rejection of negatives). Again, insufficient barriers (we
     might end up with inconsistent observed values of ->d_inode and
     ->d_flags). Fixed by switching to a new primitive that does the
     checks itself and returns ERR_PTR(-ENOENT) instead of a negative
     dentry. That way we get rid of boilerplate converting negatives
     into ERR_PTR(-ENOENT) in the callers and have a single place to
     deal with the barrier-related mess - inside fs/namei.c rather than
     in every caller out there.

  The guts of pathname resolution *do* need to be careful - the race
  found by Ritesh is real, as well as several similar races.
  Fortunately, it turns out that we can take care of that with fairly
  local changes in there.

  The tree-wide audit had not been fun, and I hate the idea of repeating
  it. I think the right approach would be to annotate the places where
  we are _not_ guaranteed ->d_inode/->d_flags stability and have sparse
  catch regressions. But I'm still not sure what would be the least
  invasive way of doing that and it's clearly the next cycle fodder"

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  fs/namei.c: fix missing barriers when checking positivity
  fix dget_parent() fastpath race
  new helper: lookup_positive_unlocked()
  fs/namei.c: pull positivity check into follow_managed()

1  2 
fs/cifs/cifsfs.c
fs/dcache.c
fs/kernfs/mount.c
fs/namei.c
fs/quota/dquot.c

Simple merge
diff --cc fs/dcache.c
Simple merge
Simple merge
diff --cc fs/namei.c
Simple merge
index 4639d53e96a32619e02f75b4a991f37b3355dc55,a37e1b117721c66e2863143125ddc25115e79bfe..b0688c02dc90df44295a52a497948c31e3db7d57
@@@ -2491,17 -2511,12 +2491,11 @@@ int dquot_quota_on_mount(struct super_b
        if (IS_ERR(dentry))
                return PTR_ERR(dentry);
  
-       if (d_really_is_negative(dentry)) {
-               error = -ENOENT;
-               goto out;
-       }
        error = security_quota_on(dentry);
        if (!error)
 -              error = vfs_load_quota_inode(d_inode(dentry), type, format_id,
 +              error = dquot_load_quota_inode(d_inode(dentry), type, format_id,
                                DQUOT_USAGE_ENABLED | DQUOT_LIMITS_ENABLED);
  
--out:
        dput(dentry);
        return error;
  }