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@xxxxxxxxxxxxxxxxxx>
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().