linux-kernel - linux-next: manual merge of the vfs tree with the vfs-brauner tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20250516100201.01a18903@canb.auug.org.au>
Date: Fri, 16 May 2025 10:02:01 +1000
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: Al Viro <viro@...IV.linux.org.uk>, Christian Brauner
 <brauner@...nel.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux Next
 Mailing List <linux-next@...r.kernel.org>, NeilBrown <neil@...wn.name>,
 NeilBrown <neilb@...e.de>
Subject: linux-next: manual merge of the vfs tree with the vfs-brauner tree

Hi all,

Today's linux-next merge of the vfs tree got a conflict in:

  Documentation/filesystems/porting.rst

between commits:

  5741909697a3 ("VFS: improve interface for lookup_one functions")
  fa6fe07d1536 ("VFS: rename lookup_one_len family to lookup_noperm and remove permission check")
  06c567403ae5 ("Use try_lookup_noperm() instead of d_hash_and_lookup() outside of VFS")

from the vfs-brauner tree and commit:

  006ff7498fe8 ("saner calling conventions for ->d_automount()")

from the vfs tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/filesystems/porting.rst
index 3111ef5592f3,749637231773..000000000000
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -1206,40 -1206,7 +1206,46 @@@ will fail-safe
  
  ---
  
 +** mandatory**
 +
 +lookup_one(), lookup_one_unlocked(), lookup_one_positive_unlocked() now
 +take a qstr instead of a name and len.  These, not the "one_len"
 +versions, should be used whenever accessing a filesystem from outside
 +that filesysmtem, through a mount point - which will have a mnt_idmap.
 +
 +---
 +
 +** mandatory**
 +
 +Functions try_lookup_one_len(), lookup_one_len(),
 +lookup_one_len_unlocked() and lookup_positive_unlocked() have been
 +renamed to try_lookup_noperm(), lookup_noperm(),
 +lookup_noperm_unlocked(), lookup_noperm_positive_unlocked().  They now
 +take a qstr instead of separate name and length.  QSTR() can be used
 +when strlen() is needed for the length.
 +
 +For try_lookup_noperm() a reference to the qstr is passed in case the
 +hash might subsequently be needed.
 +
 +These function no longer do any permission checking - they previously
 +checked that the caller has 'X' permission on the parent.  They must
 +ONLY be used internally by a filesystem on itself when it knows that
 +permissions are irrelevant or in a context where permission checks have
 +already been performed such as after vfs_path_parent_lookup()
 +
 +---
 +
 +** mandatory**
 +
 +d_hash_and_lookup() is no longer exported or available outside the VFS.
 +Use try_lookup_noperm() instead.  This adds name validation and takes
 +arguments in the opposite order but is otherwise identical.
 +
 +Using try_lookup_noperm() will require linux/namei.h to be included.
 +
++---
++
+ **mandatory**
+ 
+ Calling conventions for ->d_automount() have changed; we should *not* grab
+ an extra reference to new mount - it should be returned with refcount 1.

Content of type "application/pgp-signature" skipped