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

[Chuck Lever]

On 5/28/26 10:28 AM, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs-brauner tree got conflicts in:
> 
>   kernel/ptrace.c
>   fs/exec.c
>   include/linux/binfmts.h
>   kernel/exec_state.c
> 
> between commits:
> 
>   6b1c66c9cca99 ("exec_state: relocate dumpable information")
>   38205ecbe6b6d ("exec: free the old mm outside the exec locks")
> 
> from the nfsd tree and commits:
> 
>   6b1c66c9cca99 ("exec_state: relocate dumpable information")
>   38205ecbe6b6d ("exec: free the old mm outside the exec locks")
> 
> from the vfs-brauner tree plus some other context from vfs-brauner
> merges.  Specifically this is due to the nfsd tree having a build break
> from the vfs-brauner tree it's based on and being held at an old version
> with it's old version of vfs-brauner while the vfs-brauner tree has been
> updated.  However since the build issue isn't fixed in the version of
> vfs-brauner I have today (I saw a patch on the list though, I guess this
> will be fixed tomorrow?) the below merge isn't actually going to be in
> -next, I'm merging the old version that's shared with nfsd and there's
> no actual conflict in today's tree.
> 
> Are you sure it's a good idea to base the nfsd tree on something
> that's rebasing?
Usually nfsd-next is based on a torvalds -rc tag. This time around,
Christian wanted to take some patches through the vfs tree that I need
for nfsd-7.2. Therefore I need to base nfsd-next on a branch that is a
merge of several vfs. topic branches plus the latest -rc tag.

vfs/vfs.all is the most convenient source of such a merged branch,
but it has proved unstable (yes, I was warned it might be!).

So I can think of a few alternate options:

1. I might create my own merged branch that grabs only the three vfs.
   branches I need. Cons: I've never done this before, I'm not certain
   my tool chain (StGit) supports git merge, and it tangles the merge
   graph even more than it already is.

2. I might drop the items in nfsd-next/testing that need the vfs.
   branches, and rebase nfsd-next on a torvalds -rc tag. Cons: that
   leaves the pre-requisites in vfs.all but they won't get an in-kernel
   consumer until v7.3

3. Maybe the only branch I need is the vfs.directory-delegation branch?
   I might rebase nfsd-next on that. But I still need -rc latest for
   patches in nfsd-testing to apply cleanly to nfsd-next.

Opinions are welcome! I'll start: I really dislike cross-tree
submission; it's a pain for everyone for not very much benefit. :-)


-- 
Chuck Lever