Message-ID: <20250731-matrosen-zugluft-12a865db6ccb@brauner>
Date: Thu, 31 Jul 2025 10:27:57 +0200
From: Christian Brauner <brauner@...nel.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [GIT PULL 09/14 for v6.17] vfs bpf

On Tue, Jul 29, 2025 at 11:15:56AM -0700, Alexei Starovoitov wrote:
> On Fri, Jul 25, 2025 at 01:27:15PM +0200, Christian Brauner wrote:
> > Hey Linus,
> > 
> > /* Summary */
> > These changes allow bpf to read extended attributes from cgroupfs.
> > This is useful in redirecting AF_UNIX socket connections based on cgroup
> > membership of the socket. One use-case is the ability to implement log
> > namespaces in systemd so services and containers are redirected to
> > different journals.
> > 
> > Please note that I plan on merging bpf changes related to the vfs
> > exclusively via vfs trees.
> 
> That was not discussed and agreed upon.
> 
> > /* Testing */
> 
> The selftests/bpf had bugs flagged by BPF CI.
> 
> > /* Conflicts */
> > 
> > Merge conflicts with mainline
> > =============================
> > 
> > No known conflicts.
> > 
> > Merge conflicts with other trees
> > ================================
> > 
> > No known conflicts.
> 
> You were told a month ago that there are conflicts
> and you were also told that the branch shouldn't be rebased,
> yet you ignored it.
> 
> > Christian Brauner (3):
> >       kernfs: remove iattr_mutex
> >       Merge patch series "Introduce bpf_cgroup_read_xattr"
> >       selftests/kernfs: test xattr retrieval
> > 
> > Song Liu (3):
> >       bpf: Introduce bpf_cgroup_read_xattr to read xattr of cgroup's node
> >       bpf: Mark cgroup_subsys_state->cgroup RCU safe
> >       selftests/bpf: Add tests for bpf_cgroup_read_xattr
> > 
> >  fs/bpf_fs_kfuncs.c                                 |  34 +++++
> >  fs/kernfs/inode.c                                  |  70 ++++-----
> >  kernel/bpf/helpers.c                               |   3 +
> >  kernel/bpf/verifier.c                              |   5 +
> >  tools/testing/selftests/bpf/bpf_experimental.h     |   3 +
> >  .../selftests/bpf/prog_tests/cgroup_xattr.c        | 145 +++++++++++++++++++
> >  .../selftests/bpf/progs/cgroup_read_xattr.c        | 158 +++++++++++++++++++++
> >  .../selftests/bpf/progs/read_cgroupfs_xattr.c      |  60 ++++++++
> 
> Now Linus needs to resolve the conflicts again.
> More details in bpf-next PR:
> https://lore.kernel.org/bpf/20250729180626.35057-1-alexei.starovoitov@gmail.com/

As many times before you seem to conveniently misremember the facts.

Every tree that has meaningful VFS changes such as adding new helpers
uses a shared branch. Such as in this case that touched kernfs and the
VFS.

The conflict arises from the fact that somehow you manage to maintain
all of the complexities of bpf but you refuse to make shared branches
work due to a simple merge conflict:

  "imo this shared branch experience wasn't good.
  We should have applied the series to bpf-next only.
  It was more bpf material than vfs. I wouldn't do this again."

  https://lore.kernel.org/r/CAADnVQ+pPt7Zt8gS0aW75WGrwjmcUcn3s37Ahd9bnLyzOfB=3g@mail.gmail.com

Something that we succesfully manage with all other subsystems. Is it
perfect? Of course not.

But instead of trying to come to a simple solution you just stop
replying. That's not how this works.

The branch had a bug and I informed you and told you how I would resolve
it in:

  https://lore.kernel.org/r/20250702-hochmoderne-abklatsch-af9c605b57b2@brauner

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.

I also explicitly told you as a reply to the very issue in the same thread:

  "Anything that touches VFS will go through VFS. Shared
  branches work just fine. We manage to do this with everyone else in the
  kernel so bpf is able to do this as well. If you'd just asked this would
  not have been an issue. Merge conflicts are a fact of kernel
  development, we all deal with it you can too."

  https://lore.kernel.org/r/20250702-anhaften-postleitzahl-06a4d4771641@brauner

For the record, I don't have a problem with some stuff going through
other trees. For example, if Jens wanted to do that I'd go "hell yeah,
let's try and make this work."

The reason I'm hesitant to do it here is because of continuous mails
like the one you sent here where you aggressively spin a story and then
try to make someone take the blame.

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.

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.

Powered by blists - more mailing lists