From: Chuck Lever <chuck.lever@oracle•com>
To: Mark Brown <broonie@kernel•org>,
Christian Brauner <brauner@kernel•org>,
Jeff Layton <jlayton@kernel•org>
Cc: Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>
Subject: Re: linux-next: manual merge of the vfs-brauner tree with the nfsd tree
Date: Thu, 28 May 2026 10:51:58 -0400 [thread overview]
Message-ID: <03ab0716-6b08-4e4a-8fe6-2d398fe03ac3@oracle.com> (raw)
In-Reply-To: <ahhRHXWXMtagI5Zi@sirena.org.uk>
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
next prev parent reply other threads:[~2026-05-28 14:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 14:28 linux-next: manual merge of the vfs-brauner tree with the nfsd tree Mark Brown
2026-05-28 14:51 ` Chuck Lever [this message]
2026-05-28 15:01 ` Mark Brown
2026-05-28 15:34 ` Chuck Lever
-- strict thread matches above, loose matches on Subject: below --
2025-11-16 20:34 Stephen Rothwell
2025-12-02 23:11 ` Stephen Rothwell
2024-10-23 21:15 Stephen Rothwell
2024-02-07 0:41 Stephen Rothwell
2024-02-07 14:40 ` Chuck Lever
2024-02-07 14:58 ` Jeff Layton
2023-05-23 23:56 Stephen Rothwell
2023-05-24 9:08 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03ab0716-6b08-4e4a-8fe6-2d398fe03ac3@oracle.com \
--to=chuck.lever@oracle$(echo .)com \
--cc=brauner@kernel$(echo .)org \
--cc=broonie@kernel$(echo .)org \
--cc=jlayton@kernel$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox