namei: don't assert S_ISDIR on a stale rcu-walk inode

lookup_inode_permission_may_exec() asserts that it is only ever handed a
directory, on the grounds that link_path_walk() has already checked
d_can_lookup().  In rcu-walk that does not follow.  step_into() samples
->d_inode and validates it against ->d_seq, but link_path_walk() loads
->d_flags again afterwards, and nothing orders that load against changes
of the dentry:

  CPU0 (rcu-walk of "x/y")              CPU1
  step_into(x)
    inode = x->d_inode   // regular file
    read_seqcount_retry(&x->d_seq) == 0
    nd->inode = inode
                                        unlink("x")
                                          d_delete()  // x goes negative
                                        mkdir("x")
                                          d_instantiate()  // same dentry
  d_can_lookup(x)        // true now
  may_lookup()
    VFS_BUG_ON_INODE(!S_ISDIR(nd->inode->i_mode))

With CONFIG_PREEMPT_RCU the walker can be preempted in that window, so it
is not limited to a few instructions.  mkdir() only gets the same dentry
back if the filesystem keeps negative dentries around.  tmpfs doesn't,
ext4 does.

Apart from the assertion the stale inode is harmless, and has been there
since before the assertion was added: nd->seq no longer matches x->d_seq,
so lookup_fast(), follow_dotdot_rcu() and try_to_unlazy() all fail with
-ECHILD and the walk is redone in ref-walk, whatever the permission check
on the old inode said.

Keep the assertion for ref-walk, where the dentry is pinned and can't
change type, and skip it for rcu-walk.  No change for kernels without
CONFIG_DEBUG_VFS.

Fixes: e631df89cd5d ("fs: speed up path lookup with cheaper handling of MAY_EXEC")
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

0 files changed, 0 insertions, 0 deletions