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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3996 bytes --]

Hi all,

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

  Documentation/filesystems/porting.rst

between commit:

  01bc8e9ae23a ("porting: document block device freeze and thaw changes")

from the vfs-brauner tree and commits:

  22e111ed6c83 ("rename(): fix the locking of subdirectories")
  a8b0026847b8 ("rename(): avoid a deadlock in the case of parents having no common ancestor")
  da549bdd15c2 ("dentry: switch the lists of children to hlist")
  2f42f1eb9093 ("Call retain_dentry() with refcount 0")
  1c18edd1b7a0 ("__dentry_kill(): new locking scheme")

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 ced3a6761329,270cef3d84d4..000000000000
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -1064,12 -1064,61 +1064,73 @@@ generic_encode_ino32_fh() explicitly
  
  ---
  
 +**recommended**
 +
 +Block device freezing and thawing have been moved to holder operations.
 +
 +Before this change, get_active_super() would only be able to find the
 +superblock of the main block device, i.e., the one stored in sb->s_bdev. Block
 +device freezing now works for any block device owned by a given superblock, not
 +just the main block device. The get_active_super() helper and bd_fsfreeze_sb
 +pointer are gone.
++
++---
++
+ **mandatory**
+ 
+ If ->rename() update of .. on cross-directory move needs an exclusion with
+ directory modifications, do *not* lock the subdirectory in question in your
+ ->rename() - it's done by the caller now [that item should've been added in
+ 28eceeda130f "fs: Lock moved directories"].
+ 
+ ---
+ 
+ **mandatory**
+ 
+ On same-directory ->rename() the (tautological) update of .. is not protected
+ by any locks; just don't do it if the old parent is the same as the new one.
+ We really can't lock two subdirectories in same-directory rename - not without
+ deadlocks.
+ 
+ ---
+ 
+ **mandatory**
+ 
+ lock_rename() and lock_rename_child() may fail in cross-directory case, if
+ their arguments do not have a common ancestor.  In that case ERR_PTR(-EXDEV)
+ is returned, with no locks taken.  In-tree users updated; out-of-tree ones
+ would need to do so.
+ 
+ ---
+ 
+ **mandatory**
+ 
+ The list of children anchored in parent dentry got turned into hlist now.
+ Field names got changed (->d_children/->d_sib instead of ->d_subdirs/->d_child
+ for anchor/entries resp.), so any affected places will be immediately caught
+ by compiler.
+ 
+ ---
+ 
+ **mandatory**
+ 
+ ->d_delete() instances are now called for dentries with ->d_lock held
+ and refcount equal to 0.  They are not permitted to drop/regain ->d_lock.
+ None of in-tree instances did anything of that sort.  Make sure yours do not...
+ 
+ --
+ 
+ **mandatory**
+ 
+ ->d_prune() instances are now called without ->d_lock held on the parent.
+ ->d_lock on dentry itself is still held; if you need per-parent exclusions (none
+ of the in-tree instances did), use your own spinlock.
+ 
+ ->d_iput() and ->d_release() are called with victim dentry still in the
+ list of parent's children.  It is still unhashed, marked killed, etc., just not
+ removed from parent's ->d_children yet.
+ 
+ Anyone iterating through the list of children needs to be aware of the
+ half-killed dentries that might be seen there; taking ->d_lock on those will
+ see them negative, unhashed and with negative refcount, which means that most
+ of the in-kernel users would've done the right thing anyway without any adjustment.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Hi all,

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

  fs/afs/dir.c

between commit:

  6dd80936618c ("afs: Use netfslib for directories")

from the vfs-brauner tree and commit:

  8281b27ee7ec ("afs_d_revalidate(): use stable name and parent inode passed by caller")

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 fs/afs/dir.c
index a843c36fc471,c6ee6257d4c6..000000000000
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@@ -597,8 -607,8 +598,8 @@@ static bool afs_lookup_one_filldir(stru
   * Do a lookup of a single name in a directory
   * - just returns the FID the dentry name maps to if found
   */
- static int afs_do_lookup_one(struct inode *dir, struct dentry *dentry,
+ static int afs_do_lookup_one(struct inode *dir, const struct qstr *name,
 -			     struct afs_fid *fid, struct key *key,
 +			     struct afs_fid *fid,
  			     afs_dataversion_t *_dir_version)
  {
  	struct afs_super_info *as = dir->i_sb->s_fs_info;
@@@ -609,10 -619,10 +610,10 @@@
  	};
  	int ret;
  
- 	_enter("{%lu},%p{%pd},", dir->i_ino, dentry, dentry);
+ 	_enter("{%lu},{%s},", dir->i_ino, name->name);
  
  	/* search the directory */
 -	ret = afs_dir_iterate(dir, &cookie.ctx, key, _dir_version);
 +	ret = afs_dir_iterate(dir, &cookie.ctx, NULL, _dir_version);
  	if (ret < 0) {
  		_leave(" = %d [iter]", ret);
  		return ret;
@@@ -1127,7 -1142,7 +1114,7 @@@ static int afs_d_revalidate(struct inod
  	afs_stat_v(dir, n_reval);
  
  	/* search the directory for this vnode */
- 	ret = afs_do_lookup_one(&dir->netfs.inode, dentry, &fid, &dir_version);
 -	ret = afs_do_lookup_one(&dir->netfs.inode, name, &fid, key, &dir_version);
++	ret = afs_do_lookup_one(&dir->netfs.inode, name, &fid, &dir_version);
  	switch (ret) {
  	case 0:
  		/* the filename maps to something */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Today's linux-next merge of the vfs tree got a conflict in:
> 
>   fs/afs/dir.c
> 
> between commit:
> 
>   6dd80936618c ("afs: Use netfslib for directories")
> 
> from the vfs-brauner tree and commit:
> 
>   8281b27ee7ec ("afs_d_revalidate(): use stable name and parent inode passed by caller")
> 
> 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.

That looks correct.

Acked-by: David Howells <dhowells@redhat.com>

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2892 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

Hi all,

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

  fs/fhandle.c

between commit:

  1c5484395f9f ("fhandle: reflow get_path_anchor()")

from the vfs-brauner tree and commit:

  8ae91ad6499b ("fold fs_struct->{lock,seq} into a seqlock")

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 fs/fhandle.c
index b1363ead6c5e,e2f8e788d33a..000000000000
--- a/fs/fhandle.c
+++ b/fs/fhandle.c
@@@ -176,24 -178,9 +176,20 @@@ static int get_path_anchor(int fd, stru
  			return -EBADF;
  		*root = fd_file(f)->f_path;
  		path_get(root);
 +		return 0;
  	}
  
 -	return 0;
 +	if (fd == AT_FDCWD) {
- 		struct fs_struct *fs = current->fs;
- 		spin_lock(&fs->lock);
- 		*root = fs->pwd;
- 		path_get(root);
- 		spin_unlock(&fs->lock);
++		get_fs_pwd(current->fs, root);
 +		return 0;
 +	}
 +
 +	if (fd == FD_PIDFS_ROOT) {
 +		pidfs_get_root(root);
 +		return 0;
 +	}
 +
 +	return -EBADF;
  }
  
  static int vfs_dentry_acceptable(void *context, struct dentry *dentry)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Al Viro]

On Tue, Jul 08, 2025 at 09:38:37AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs tree got a conflict in:
> 
>   fs/fhandle.c
> 
> between commit:
> 
>   1c5484395f9f ("fhandle: reflow get_path_anchor()")
> 
> from the vfs-brauner tree and commit:
> 
>   8ae91ad6499b ("fold fs_struct->{lock,seq} into a seqlock")
> 
> 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.

Umm...  Let's do it that way - fs/fhandle.c chunk of that commit is
trivially split off and the rest should not conflict at all.

Christian, would you mind throwing this on top of your vfs.pidfs?  I'm dropping
that part from my #work.misc commit...

[PATCH] get_path_from_fd(): don't open-code get_fs_pwd()
    
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/fhandle.c b/fs/fhandle.c
index b1363ead6c5e..7c236f64cdea 100644
--- a/fs/fhandle.c
+++ b/fs/fhandle.c
@@ -180,11 +180,7 @@ static int get_path_anchor(int fd, struct path *root)
 	}
 
 	if (fd == AT_FDCWD) {
-		struct fs_struct *fs = current->fs;
-		spin_lock(&fs->lock);
-		*root = fs->pwd;
-		path_get(root);
-		spin_unlock(&fs->lock);
+		get_fs_pwd(current->fs, root);
 		return 0;
 	}
 

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

[Al Viro]

On Tue, Jul 08, 2025 at 01:25:09AM +0100, Al Viro wrote:

> Umm...  Let's do it that way - fs/fhandle.c chunk of that commit is
> trivially split off and the rest should not conflict at all.
> 
> Christian, would you mind throwing this on top of your vfs.pidfs?  I'm dropping
> that part from my #work.misc commit...

Argh...  Sorry, no go - that chunk needs to go before the rest of conversion
commit.  Hmm...

See vfs/vfs.git #vfs-6.17.fs_struct; that branches off your "reflow" commit
and it merges clean with #vfs.all, AFAICS.

Are you OK with that variant?  I've no strong preferences re branchpoints,
but some folks do - no idea if you have any policies in that respect.

If you don't have any problems with it, just merge it into #vfs.all
and I'll drop that commit from #work.misc

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

[Christian Brauner]

On Tue, Jul 08, 2025 at 01:45:50AM +0100, Al Viro wrote:
> On Tue, Jul 08, 2025 at 01:25:09AM +0100, Al Viro wrote:
> 
> > Umm...  Let's do it that way - fs/fhandle.c chunk of that commit is
> > trivially split off and the rest should not conflict at all.
> > 
> > Christian, would you mind throwing this on top of your vfs.pidfs?  I'm dropping
> > that part from my #work.misc commit...
> 
> Argh...  Sorry, no go - that chunk needs to go before the rest of conversion
> commit.  Hmm...
> 
> See vfs/vfs.git #vfs-6.17.fs_struct; that branches off your "reflow" commit
> and it merges clean with #vfs.all, AFAICS.
> 
> Are you OK with that variant?  I've no strong preferences re branchpoints,
> but some folks do - no idea if you have any policies in that respect.

Whatever makes collaboration here easier I'm happy to go with! Thanks
for jumping on this so quicly?

> If you don't have any problems with it, just merge it into #vfs.all
> and I'll drop that commit from #work.misc

Sure! Let me grab it.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]

Hi all,

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

  fs/namespace.c

between commits:

  807602d8cfc8 ("vfs: output mount_too_revealing() errors to fscontext")
  1e5f0fb41fcc ("vfs: fs/namespace.c: remove ms_flags argument from do_remount")

from the vfs_brauner tree and commits:

  5423426a79dd ("switch do_new_mount_fc() to fc_mount()")
  308a022f41bd ("do_new_mount_fc(): use __free() to deal with dropping mnt on failure")
  ead5706f63cd ("do_{loopback,change_type,remount,reconfigure_mnt}(): constify struct path argument")

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 fs/namespace.c
index 92980f758fd4,aeeb33bf3e7b..000000000000
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@@ -3298,7 -3310,7 +3319,7 @@@ static int do_reconfigure_mnt(const str
   * If you've mounted a non-root directory somewhere and want to do remount
   * on it - tough luck.
   */
- static int do_remount(struct path *path, int sb_flags,
 -static int do_remount(const struct path *path, int ms_flags, int sb_flags,
++static int do_remount(const struct path *path, int sb_flags,
  		      int mnt_flags, void *data)
  {
  	int err;
@@@ -3738,30 -3720,20 +3729,22 @@@ static int do_new_mount_fc(struct fs_co
  	if (IS_ERR(mnt))
  		return PTR_ERR(mnt);
  
+ 	sb = fc->root->d_sb;
+ 	error = security_sb_kern_mount(sb);
+ 	if (unlikely(error))
+ 		return error;
+ 
 -	if (unlikely(mount_too_revealing(sb, &mnt_flags)))
++	if (unlikely(mount_too_revealing(sb, &mnt_flags))) {
++		errorfcp(fc, "VFS", "Mount too revealing");
+ 		return -EPERM;
++	}
+ 
  	mnt_warn_timestamp_expiry(mountpoint, mnt);
  
- 	error = lock_mount(mountpoint, &mp);
- 	if (!error) {
- 		error = do_add_mount(real_mount(mnt), mp.mp,
- 				     mountpoint, mnt_flags);
- 		unlock_mount(&mp);
- 	}
- 	if (error < 0)
- 		mntput(mnt);
+ 	LOCK_MOUNT(mp, mountpoint);
+ 	error = do_add_mount(real_mount(mnt), &mp, mnt_flags);
+ 	if (!error)
+ 		retain_and_null_ptr(mnt); // consumed on success
  	return error;
  }
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3223 bytes --]

Hi all,

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

  fs/namespace.c

between commit:

  be5f21d3985f0 ("ns: add ns_common_free()")

from the vfs-brauner tree and commit:

  7bb4c851dcb7a ("copy_mnt_ns(): use the regular mechanism for freeing empty mnt_ns on failure")

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.

diff --cc fs/namespace.c
index 880cbabe6f957,b9430a5cc987f..0000000000000
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@@ -90,7 -80,16 +90,15 @@@ static DECLARE_RWSEM(namespace_sem)
  static HLIST_HEAD(unmounted);	/* protected by namespace_sem */
  static LIST_HEAD(ex_mountpoints); /* protected by namespace_sem */
  static struct mnt_namespace *emptied_ns; /* protected by namespace_sem */
 -static DEFINE_SEQLOCK(mnt_ns_tree_lock);
  
+ static inline void namespace_lock(void);
+ static void namespace_unlock(void);
+ DEFINE_LOCK_GUARD_0(namespace_excl, namespace_lock(), namespace_unlock())
+ DEFINE_LOCK_GUARD_0(namespace_shared, down_read(&namespace_sem),
+ 				      up_read(&namespace_sem))
+ 
+ DEFINE_FREE(mntput, struct vfsmount *, if (!IS_ERR(_T)) mntput(_T))
+ 
  #ifdef CONFIG_FSNOTIFY
  LIST_HEAD(notify_list); /* protected by namespace_sem */
  #endif
@@@ -3229,7 -3304,7 +3244,7 @@@ static int do_reconfigure_mnt(const str
   * If you've mounted a non-root directory somewhere and want to do remount
   * on it - tough luck.
   */
- static int do_remount(struct path *path, int sb_flags,
 -static int do_remount(const struct path *path, int ms_flags, int sb_flags,
++static int do_remount(const struct path *path, int sb_flags,
  		      int mnt_flags, void *data)
  {
  	int err;
@@@ -4164,10 -4204,7 +4133,8 @@@ struct mnt_namespace *copy_mnt_ns(u64 f
  		copy_flags |= CL_SLAVE;
  	new = copy_tree(old, old->mnt.mnt_root, copy_flags);
  	if (IS_ERR(new)) {
+ 		emptied_ns = new_ns;
 +		namespace_unlock();
- 		ns_common_free(ns);
- 		dec_mnt_namespaces(new_ns->ucounts);
- 		mnt_ns_release(new_ns);
  		return ERR_CAST(new);
  	}
  	if (user_ns != ns->user_ns) {
@@@ -4205,14 -4241,7 +4171,7 @@@
  		while (p->mnt.mnt_root != q->mnt.mnt_root)
  			p = next_mnt(skip_mnt_tree(p), old);
  	}
- 	namespace_unlock();
- 
- 	if (rootmnt)
- 		mntput(rootmnt);
- 	if (pwdmnt)
- 		mntput(pwdmnt);
- 
 -	mnt_ns_tree_add(new_ns);
 +	ns_tree_add_raw(new_ns);
  	return new_ns;
  }
  
@@@ -6095,14 -6093,12 +6027,12 @@@ void __init mnt_init(void
  
  void put_mnt_ns(struct mnt_namespace *ns)
  {
 -	if (!refcount_dec_and_test(&ns->ns.count))
 +	if (!ns_ref_put(ns))
  		return;
- 	namespace_lock();
+ 	guard(namespace_excl)();
  	emptied_ns = ns;
- 	lock_mount_hash();
+ 	guard(mount_writer)();
  	umount_tree(ns->root, 0);
- 	unlock_mount_hash();
- 	namespace_unlock();
  }
  
  struct vfsmount *kern_mount(struct file_system_type *type)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]

Hi all,

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

  fs/namei.c
  include/linux/namei.h

between commit:

  3d18f80ce181b ("VFS: rename kern_path_locked() and related functions.")

from the vfs-brauner tree and commit:

  63dbfb077cdad ("done_path_create(): constify path argument")

from the vfs tree (BTW Documentation/filesystems/porting.rst has a
user_path_locked_at() reference).

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.

diff --cc fs/namei.c
index 507ca0d7878d6,ba8bf73d2f9cf..0000000000000
--- a/fs/namei.c
+++ b/fs/namei.c
@@@ -4254,9 -4168,9 +4254,9 @@@ struct dentry *start_creating_path(int 
  	putname(filename);
  	return res;
  }
 -EXPORT_SYMBOL(kern_path_create);
 +EXPORT_SYMBOL(start_creating_path);
  
- void end_creating_path(struct path *path, struct dentry *dentry)
 -void done_path_create(const struct path *path, struct dentry *dentry)
++void end_creating_path(const struct path *path, struct dentry *dentry)
  {
  	if (!IS_ERR(dentry))
  		dput(dentry);
diff --cc include/linux/namei.h
index a7800ef04e761,75c0b665fbd41..0000000000000
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@@ -57,17 -57,13 +57,17 @@@ struct dentry *lookup_one_qstr_excl(con
  				    struct dentry *base,
  				    unsigned int flags);
  extern int kern_path(const char *, unsigned, struct path *);
 +struct dentry *kern_path_parent(const char *name, struct path *parent);
  
 -extern struct dentry *kern_path_create(int, const char *, struct path *, unsigned int);
 -extern struct dentry *user_path_create(int, const char __user *, struct path *, unsigned int);
 -extern void done_path_create(const struct path *, struct dentry *);
 -extern struct dentry *kern_path_locked(const char *, struct path *);
 -extern struct dentry *kern_path_locked_negative(const char *, struct path *);
 -extern struct dentry *user_path_locked_at(int , const char __user *, struct path *);
 +extern struct dentry *start_creating_path(int, const char *, struct path *, unsigned int);
 +extern struct dentry *start_creating_user_path(int, const char __user *, struct path *, unsigned int);
- extern void end_creating_path(struct path *, struct dentry *);
++extern void end_creating_path(const struct path *, struct dentry *);
 +extern struct dentry *start_removing_path(const char *, struct path *);
 +extern struct dentry *start_removing_user_path_at(int , const char __user *, struct path *);
 +static inline void end_removing_path(struct path *path , struct dentry *dentry)
 +{
 +	end_creating_path(path, dentry);
 +}
  int vfs_path_parent_lookup(struct filename *filename, unsigned int flags,
  			   struct path *parent, struct qstr *last, int *type,
  			   const struct path *root);

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 4162 bytes --]

Hi all,

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

  fs/namespace.c

between commit:

  59bfb66816809 ("listmount: don't call path_put() under namespace semaphore")

from the vfs-brauner tree and commit:

  2aec880c1cdf1 ("path_is_under(): use guards")

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.

diff --cc fs/namespace.c
index ef64472c4e15b,b9430a5cc987f..0000000000000
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@@ -90,7 -80,16 +90,15 @@@ static DECLARE_RWSEM(namespace_sem)
  static HLIST_HEAD(unmounted);	/* protected by namespace_sem */
  static LIST_HEAD(ex_mountpoints); /* protected by namespace_sem */
  static struct mnt_namespace *emptied_ns; /* protected by namespace_sem */
 -static DEFINE_SEQLOCK(mnt_ns_tree_lock);
  
+ static inline void namespace_lock(void);
+ static void namespace_unlock(void);
+ DEFINE_LOCK_GUARD_0(namespace_excl, namespace_lock(), namespace_unlock())
+ DEFINE_LOCK_GUARD_0(namespace_shared, down_read(&namespace_sem),
+ 				      up_read(&namespace_sem))
+ 
+ DEFINE_FREE(mntput, struct vfsmount *, if (!IS_ERR(_T)) mntput(_T))
+ 
  #ifdef CONFIG_FSNOTIFY
  LIST_HEAD(notify_list); /* protected by namespace_sem */
  #endif
@@@ -3229,7 -3304,7 +3244,7 @@@ static int do_reconfigure_mnt(const str
   * If you've mounted a non-root directory somewhere and want to do remount
   * on it - tough luck.
   */
- static int do_remount(struct path *path, int sb_flags,
 -static int do_remount(const struct path *path, int ms_flags, int sb_flags,
++static int do_remount(const struct path *path, int sb_flags,
  		      int mnt_flags, void *data)
  {
  	int err;
@@@ -4205,14 -4241,7 +4170,7 @@@ struct mnt_namespace *copy_mnt_ns(u64 f
  		while (p->mnt.mnt_root != q->mnt.mnt_root)
  			p = next_mnt(skip_mnt_tree(p), old);
  	}
- 	namespace_unlock();
- 
- 	if (rootmnt)
- 		mntput(rootmnt);
- 	if (pwdmnt)
- 		mntput(pwdmnt);
- 
 -	mnt_ns_tree_add(new_ns);
 +	ns_tree_add_raw(new_ns);
  	return new_ns;
  }
  
@@@ -5897,22 -5900,12 +5827,23 @@@ retry
  	return ret;
  }
  
 +struct klistmount {
 +	u64 last_mnt_id;
 +	u64 mnt_parent_id;
 +	u64 *kmnt_ids;
 +	u32 nr_mnt_ids;
 +	struct mnt_namespace *ns;
 +	struct path root;
 +};
 +
+ /* locks: namespace_shared */
 -static ssize_t do_listmount(struct mnt_namespace *ns, u64 mnt_parent_id,
 -			    u64 last_mnt_id, u64 *mnt_ids, size_t nr_mnt_ids,
 -			    bool reverse)
 +static ssize_t do_listmount(struct klistmount *kls, bool reverse)
  {
 -	struct path root __free(path_put) = {};
 +	struct mnt_namespace *ns = kls->ns;
 +	u64 mnt_parent_id = kls->mnt_parent_id;
 +	u64 last_mnt_id = kls->last_mnt_id;
 +	u64 *mnt_ids = kls->kmnt_ids;
 +	size_t nr_mnt_ids = kls->nr_mnt_ids;
  	struct path orig;
  	struct mount *r, *first;
  	ssize_t ret;
@@@ -6040,8 -6012,9 +5971,8 @@@ SYSCALL_DEFINE4(listmount, const struc
  	 * We only need to guard against mount topology changes as
  	 * listmount() doesn't care about any mount properties.
  	 */
- 	scoped_guard(rwsem_read, &namespace_sem)
+ 	scoped_guard(namespace_shared)
 -		ret = do_listmount(ns, kreq.mnt_id, last_mnt_id, kmnt_ids,
 -				   nr_mnt_ids, (flags & LISTMOUNT_REVERSE));
 +		ret = do_listmount(&kls, (flags & LISTMOUNT_REVERSE));
  	if (ret <= 0)
  		return ret;
  
@@@ -6124,14 -6093,12 +6055,12 @@@ void __init mnt_init(void
  
  void put_mnt_ns(struct mnt_namespace *ns)
  {
 -	if (!refcount_dec_and_test(&ns->ns.count))
 +	if (!ns_ref_put(ns))
  		return;
- 	namespace_lock();
+ 	guard(namespace_excl)();
  	emptied_ns = ns;
- 	lock_mount_hash();
+ 	guard(mount_writer)();
  	umount_tree(ns->root, 0);
- 	unlock_mount_hash();
- 	namespace_unlock();
  }
  
  struct vfsmount *kern_mount(struct file_system_type *type)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

Hi all,

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

  Documentation/filesystems/porting.rst

between commit:

  3d18f80ce181b ("VFS: rename kern_path_locked() and related functions.")

from the vfs-brauner tree and commit:

  b28f9eba12a49 ("change the calling conventions for vfs_parse_fs_string()")

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.

diff --cc Documentation/filesystems/porting.rst
index 78c3d07c0c08e,ab48ab3f6eb21..0000000000000
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -1290,10 -1290,10 +1290,22 @@@ parameters for the file system to set t
  
  **mandatory**
  
 +Several functions are renamed:
 +
 +-  kern_path_locked -> start_removing_path
 +-  kern_path_create -> start_creating_path
 +-  user_path_create -> start_creating_user_path
 +-  user_path_locked_at -> start_removing_user_path_at
 +-  done_path_create -> end_creating_path
++
++---
++
++**mandatory**
++
+ Calling conventions for vfs_parse_fs_string() have changed; it does *not*
+ take length anymore (value ? strlen(value) : 0 is used).  If you want
+ a different length, use
+ 
+ 	vfs_parse_fs_qstr(fc, key, &QSTR_LEN(value, len))
+ 
+ instead.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

Hi all,

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

  Documentation/filesystems/porting.rst

between commit:

  fe497f0759e0 ("VFS: change vfs_mkdir() to unlock on failure.")

from the vfs-brauner tree and commit:

  fc45aee66223 ("get rid of kill_litter_super()")

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 d33429294252,4921b3b0662a..000000000000
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -1314,11 -1314,5 +1314,18 @@@ instead
  
  **mandatory**
  
 +vfs_mkdir() now returns a dentry - the one returned by ->mkdir().  If
 +that dentry is different from the dentry passed in, including if it is
 +an IS_ERR() dentry pointer, the original dentry is dput().
 +
 +When vfs_mkdir() returns an error, and so both dputs() the original
 +dentry and doesn't provide a replacement, it also unlocks the parent.
 +Consequently the return value from vfs_mkdir() can be passed to
 +end_creating() and the parent will be unlocked precisely when necessary.
++
++---
++
++**mandatory**
++
+ kill_litter_super() is gone; convert to DCACHE_PERSISTENT use (as all
+ in-tree filesystems have done).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

Hi all,

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

  fs/dcache.c

between commits:

  31e332b911fc ("fs: add missing fences to I_NEW handling")
  b4dbfd8653b3 ("Coccinelle-based conversion to use ->i_state accessors")
  1e3c3784221a ("fs: rework I_NEW handling to operate without fences")

from the vfs-brauner tree and commit:

  bacdf1d70bbe ("primitives for maintaining persisitency")

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 fs/dcache.c
index 3204cc55b566,824d620bb563..000000000000
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@@ -1986,9 -2012,17 +2019,11 @@@ void d_instantiate_new(struct dentry *e
  	lockdep_annotate_inode_mutex_key(inode);
  	security_d_instantiate(entry, inode);
  	spin_lock(&inode->i_lock);
+ 	spin_lock(&entry->d_lock);
  	__d_instantiate(entry, inode);
+ 	spin_unlock(&entry->d_lock);
 -	WARN_ON(!(inode->i_state & I_NEW));
 -	inode->i_state &= ~I_NEW & ~I_CREATING;
 -	/*
 -	 * Pairs with the barrier in prepare_to_wait_event() to make sure
 -	 * ___wait_var_event() either sees the bit cleared or
 -	 * waitqueue_active() check in wake_up_var() sees the waiter.
 -	 */
 -	smp_mb();
 +	WARN_ON(!(inode_state_read(inode) & I_NEW));
 +	inode_state_clear(inode, I_NEW | I_CREATING);
  	inode_wake_up_bit(inode, __I_NEW);
  	spin_unlock(&inode->i_lock);
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]

Hi all,

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

  fs/debugfs/inode.c

between commit:

  8b45b9a88233 ("debugfs: rename end_creating() to debugfs_end_creating()")

from the vfs-brauner tree and commits:

  ebb54484c3df ("convert debugfs")
  0703b36e4e1c ("debugfs: remove duplicate checks in callers of start_creating()")

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 fs/debugfs/inode.c
index 532bd7c46baf,25a554331ac4..000000000000
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@@ -403,18 -403,17 +403,17 @@@ static struct dentry *debugfs_start_cre
  	return dentry;
  }
  
 -static struct dentry *failed_creating(struct dentry *dentry)
 +static struct dentry *debugfs_failed_creating(struct dentry *dentry)
  {
- 	inode_unlock(d_inode(dentry->d_parent));
- 	dput(dentry);
+ 	simple_done_creating(dentry);
  	simple_release_fs(&debugfs_mount, &debugfs_mount_count);
  	return ERR_PTR(-ENOMEM);
  }
  
 -static struct dentry *end_creating(struct dentry *dentry)
 +static struct dentry *debugfs_end_creating(struct dentry *dentry)
  {
- 	inode_unlock(d_inode(dentry->d_parent));
- 	return dentry;
+ 	simple_done_creating(dentry);
+ 	return dentry; // borrowed
  }
  
  static struct dentry *__debugfs_create_file(const char *name, umode_t mode,
@@@ -456,9 -450,9 +450,9 @@@
  	DEBUGFS_I(inode)->raw = real_fops;
  	DEBUGFS_I(inode)->aux = (void *)aux;
  
- 	d_instantiate(dentry, inode);
+ 	d_make_persistent(dentry, inode);
  	fsnotify_create(d_inode(dentry->d_parent), dentry);
 -	return end_creating(dentry);
 +	return debugfs_end_creating(dentry);
  }
  
  struct dentry *debugfs_create_file_full(const char *name, umode_t mode,
@@@ -602,10 -591,10 +591,10 @@@ struct dentry *debugfs_create_dir(cons
  
  	/* directory inodes start off with i_nlink == 2 (for "." entry) */
  	inc_nlink(inode);
- 	d_instantiate(dentry, inode);
+ 	d_make_persistent(dentry, inode);
  	inc_nlink(d_inode(dentry->d_parent));
  	fsnotify_mkdir(d_inode(dentry->d_parent), dentry);
 -	return end_creating(dentry);
 +	return debugfs_end_creating(dentry);
  }
  EXPORT_SYMBOL_GPL(debugfs_create_dir);
  
@@@ -649,10 -633,10 +633,10 @@@ struct dentry *debugfs_create_automount
  	DEBUGFS_I(inode)->automount = f;
  	/* directory inodes start off with i_nlink == 2 (for "." entry) */
  	inc_nlink(inode);
- 	d_instantiate(dentry, inode);
+ 	d_make_persistent(dentry, inode);
  	inc_nlink(d_inode(dentry->d_parent));
  	fsnotify_mkdir(d_inode(dentry->d_parent), dentry);
 -	return end_creating(dentry);
 +	return debugfs_end_creating(dentry);
  }
  EXPORT_SYMBOL(debugfs_create_automount);
  
@@@ -704,8 -688,8 +688,8 @@@ struct dentry *debugfs_create_symlink(c
  	inode->i_mode = S_IFLNK | S_IRWXUGO;
  	inode->i_op = &debugfs_symlink_inode_operations;
  	inode->i_link = link;
- 	d_instantiate(dentry, inode);
+ 	d_make_persistent(dentry, inode);
 -	return end_creating(dentry);
 +	return debugfs_end_creating(dentry);
  }
  EXPORT_SYMBOL_GPL(debugfs_create_symlink);
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

Hi all,

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

  security/apparmor/apparmorfs.c

between commit:

  7bb1eb45e43c ("VFS: introduce start_removing_dentry()")

from the vfs-brauner tree and commit:

  eb028c33451a ("d_make_discardable(): warn if given a non-persistent dentry")

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 security/apparmor/apparmorfs.c
index 9d08d103f142,9b9090d38ea2..000000000000
--- a/security/apparmor/apparmorfs.c
+++ b/security/apparmor/apparmorfs.c
@@@ -355,17 -355,22 +355,22 @@@ static void aafs_remove(struct dentry *
  	if (!dentry || IS_ERR(dentry))
  		return;
  
 +	/* ->d_parent is stable as rename is not supported */
  	dir = d_inode(dentry->d_parent);
 -	inode_lock(dir);
 -	if (simple_positive(dentry)) {
 +	dentry = start_removing_dentry(dentry->d_parent, dentry);
 +	if (!IS_ERR(dentry) && simple_positive(dentry)) {
- 		if (d_is_dir(dentry))
- 			simple_rmdir(dir, dentry);
- 		else
- 			simple_unlink(dir, dentry);
+ 		if (d_is_dir(dentry)) {
+ 			if (!WARN_ON(!simple_empty(dentry))) {
+ 				__simple_rmdir(dir, dentry);
+ 				dput(dentry);
+ 			}
+ 		} else {
+ 			__simple_unlink(dir, dentry);
+ 			dput(dentry);
+ 		}
  		d_delete(dentry);
 -		dput(dentry);
  	}
 -	inode_unlock(dir);
 +	end_removing(dentry);
  	simple_release_fs(&aafs_mnt, &aafs_count);
  }
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

Hi all,

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

  Documentation/filesystems/porting.rst

between commit:

  2b10994be716 ("filelock: default to returning -EINVAL when ->setlease operation is NULL")

from the vfs-brauner tree and commits:

  d04faed9ff84 ("non-consuming variant of do_renameat2()")
  7335480a8461 ("non-consuming variant of do_linkat()")
  82f616740547 ("non-consuming variant of do_symlinkat()")
  efa68e343b3b ("non-consuming variant of do_mkdirat()")
  f2a62ccef4ad ("non-consuming variant of do_mknodat()")
  5f6a811e9abe ("non-consuming variants of do_{unlinkat,rmdir}()")

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 ed3ac56e3c76,2b4dddfe6c66..000000000000
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -1336,7 -1339,6 +1336,15 @@@ in-tree filesystems have done)
  
  **mandatory**
  
 +The ->setlease() file_operation must now be explicitly set in order to provide
 +support for leases. When set to NULL, the kernel will now return -EINVAL to
 +attempts to set a lease. Filesystems that wish to use the kernel-internal lease
 +implementation should set it to generic_setlease().
++
++---
++
++**mandatory**
++
+ do_{mkdir,mknod,link,symlink,renameat2,rmdir,unlink}() are gone; filename_...()
+ counterparts replace those.  The difference is that the former used to consume
+ filename references; the latter do not.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

Hi all,

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

  Documentation/filesystems/porting.rst

between commit:

  2b10994be716b ("filelock: default to returning -EINVAL when ->setlease operation is NULL")

from the vfs-brauner tree and commit:

  e6d50234ccb9f ("non-consuming variant of do_renameat2()")

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.

diff --cc Documentation/filesystems/porting.rst
index ed3ac56e3c768,909c7d0232f97..0000000000000
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -1336,7 -1339,9 +1336,18 @@@ in-tree filesystems have done)
  
  **mandatory**
  
 +The ->setlease() file_operation must now be explicitly set in order to provide
 +support for leases. When set to NULL, the kernel will now return -EINVAL to
 +attempts to set a lease. Filesystems that wish to use the kernel-internal lease
 +implementation should set it to generic_setlease().
++
++---
++
++**mandatory**
++
+ fs/namei.c primitives that consume filesystem references (do_renameat2(),
+ do_linkat(), do_symlinkat(), do_mkdirat(), do_mknodat(), do_unlinkat()
+ and do_rmdir()) are gone; they are replaced with non-consuming analogues
+ (filename_renameat2(), etc.)
+ Callers are adjusted - responsibility for dropping the filenames belongs
+ to them now.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

Hi all,

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

  Documentation/filesystems/porting.rst

between commits:

  336faf5d9115c ("VFS: make lookup_one_qstr_excl() static.")
  4d94ce88c77e7 ("VFS: unexport lock_rename(), lock_rename_child(), unlock_rename()")

from the vfs-brauner tree and commit:

  408d8af01f3a4 ("for_each_alias(): helper macro for iterating through dentries of given inode")

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.

diff --cc Documentation/filesystems/porting.rst
index d02aa57e44775,9a9babd9ec486..0000000000000
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -1364,14 -1364,10 +1364,22 @@@ lifetime, consider using inode_set_cach
  
  ---
  
 +**mandatory**
 +
 +lookup_one_qstr_excl() is no longer exported - use start_creating() or
 +similar.
 +---
 +
 +** mandatory**
 +
 +lock_rename(), lock_rename_child(), unlock_rename() are no
 +longer available.  Use start_renaming() or similar.
++---
 +
+ **recommended**
+ 
+ If you really need to iterate through dentries for given inode, use
+ for_each_alias(dentry, inode) instead of hlist_for_each_entry; better
+ yet, see if any of the exported primitives could be used instead of
+ the entire loop.  You still need to hold ->i_lock of the inode over
+ either form of manual loop.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Al Viro]

On Wed, Apr 08, 2026 at 01:43:50PM +0100, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs tree got a conflict in:
> 
>   Documentation/filesystems/porting.rst
> 
> between commits:
> 
>   336faf5d9115c ("VFS: make lookup_one_qstr_excl() static.")
>   4d94ce88c77e7 ("VFS: unexport lock_rename(), lock_rename_child(), unlock_rename()")
> 
> from the vfs-brauner tree and commit:
> 
>   408d8af01f3a4 ("for_each_alias(): helper macro for iterating through dentries of given inode")
> 
> 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.

FWIW, I suspect that it might be a good policy to put notes on likely
-next conflicts and their suggested resolution in the head commits of
#for-next branches.  What I'd done yesterday was
commit e82ff9b6cb767fc823d5e461034f32388c4092a2 (vfs/for-next, for-next)
Merge: e252ed898857 14a51045e10d
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Apr 8 03:17:38 2026 -0400
 
    Merge branches 'work.coda' and 'work.dcache-busy-wait' into for-next
 
    -next: trivial conflict in Documentation/filesystems/porting.rst (several
    branches append to the end of that file, order of entries is irrelevant)
 
    -next: hopefully no cifs conflict anymore, but if they still use the
    variant with ->d_u.d_alias in cifs_d_mark_tmpfile(), just replace the
    line in question with
            BUG_ON(d_really_is_positive(dentry));
    as in fs/dcache.c:d_mark_tmpfile().

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Wed, Apr 08, 2026 at 06:16:39PM +0100, Al Viro wrote:
> On Wed, Apr 08, 2026 at 01:43:50PM +0100, Mark Brown wrote:

> > 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.

> FWIW, I suspect that it might be a good policy to put notes on likely
> -next conflicts and their suggested resolution in the head commits of
> #for-next branches.  What I'd done yesterday was

Ah, I'll try to remember to look for those, thanks!  It's helpful to
have some ideas for what to do.  People often drop me emails about this
stuff as well if that's easier for people.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]