linux-kernel - Re: [GIT PULL 09/14 for v6.17] vfs bpf

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQKMNq3vWDzYocS6QojBDXDzC2RdE=VzTnd7C_SN6Jhn_g@mail.gmail.com>
Date: Thu, 31 Jul 2025 14:57:52 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Christian Brauner <brauner@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	bpf <bpf@...r.kernel.org>
Subject: Re: [GIT PULL 09/14 for v6.17] vfs bpf

On Thu, Jul 31, 2025 at 1:28 AM Christian Brauner <brauner@...nel.org> wrote:
>
> It's been in -next a few days. Instead of slapping some hotfix on top
> that leaves the tree in a broken state the fix was squashed. In other
> words you would have to reapply the series anyway.

That's not how stable branches work. The whole point of a stable
branch is that sha-s should not change. You don't squash things
after a branch is created.
That extra fix could have been easily added on top.

> I mean, your mail is very short of "Linus, I'm subtly telling you what
> mean Christian did wrong and that he's rebased, which I know you hate
> and you have to resolve merge conflicts so please yell at him.". Come
> on.

Not subtly. You made a mistake and instead of admitting it
you're doubling down on your wrong git process.

> I work hard to effectively cooperate with you but until there is a
> good-faith mutual relationship on-list I don't want meaningful VFS work
> going through the bpf tree. You can take it or leave it and I would
> kindly ask Linus to respect that if he agrees.

Look, you took bpf patches that BPF CI flagged as broken
and bpf maintainers didn't even ack.
Out of 4 patches that you applied one was yours that
touched VFS and 3 were bpf related.
That was a wtf moment, but we didn't complain,
since the feature is useful, so we were happy to see
it land even in this half broken form.
We applied your "stable" branch to bpf-next and added fixes on top.
Then you squashed "hotfix".
That made all of our fixes in bpf-next to become conflicts.
We cannot reapply your branch. We don't rebase the trees.
That was the policy for years. Started long ago during
net-next era and now in bpf-next too.
This time we were lucky that conflicts were not that bad
and it was easy enough for Linus to deal with them,
but that must not repeat.

Do not touch bpf patches if you refuse to follow
stable branch process that everyone else does.
And it's not VFS. It's really just you, Christian.
Back in August 2024 Al created a true stable branch
vfs/stable-struct_fd. We pulled it into bpf-next
in commit 50470d3899cd ("Merge remote-tracking branch 'vfs/stable-struct_fd'")
While Al sent a PR for it during the merge window:
https://lore.kernel.org/all/20240923034731.GF3413968@ZenIV/
On the kernel/bpf/* side we added more changes on top of Al's work,
and, surprise, there were no conflicts during the merge window.
That's how stable branches meant to work.