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

Message-ID: <20250804-dammbruch-babypuppen-689a8e3421df@brauner>
Date: Mon, 4 Aug 2025 16:24:01 +0200
From: Christian Brauner <brauner@...nel.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
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 02:57:52PM -0700, Alexei Starovoitov wrote:
> 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.

Ah, I see what you're complaining about now. But I'm still not happy
that we didn't manage to resolve this confusion earlier.

I was not clear in what way you did rely on that branch and that you
relied on me not folding in the mutex fix especially because you didn't
reply when I said I would fold it and you said that putting fixes on top
wouldn't work upthread.

If I'm aware that a branch is shared and relied upon then I won't change it.
I would've immediately rolled it back would I have know that this causes
issues for you but to me everything looked fine when I didn't hear back.