Re: [PATCH v3 bpf-next 0/4] Introduce bpf_cgroup_read_xattr

[Christian Brauner <brauner@kernel.org>]

On Tue, Jul 01, 2025 at 07:51:55AM -0700, Alexei Starovoitov wrote:
> On Tue, Jul 1, 2025 at 1:32 AM Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Thu, Jun 26, 2025 at 07:14:20PM -0700, Alexei Starovoitov wrote:
> > > On Mon, Jun 23, 2025 at 4:03 AM Christian Brauner <brauner@kernel.org> wrote:
> > > >
> > > > On Sun, 22 Jun 2025 23:38:50 -0700, Song Liu wrote:
> > > > > Introduce a new kfunc bpf_cgroup_read_xattr, which can read xattr from
> > > > > cgroupfs nodes. The primary users are LSMs, cgroup programs, and sched_ext.
> > > > >
> > > >
> > > > Applied to the vfs-6.17.bpf branch of the vfs/vfs.git tree.
> > > > Patches in the vfs-6.17.bpf branch should appear in linux-next soon.
> > >
> > > Thanks.
> > > Now merged into bpf-next/master as well.
> > >
> > > > Please report any outstanding bugs that were missed during review in a
> > > > new review to the original patch series allowing us to drop it.
> > >
> > > bugs :(
> > >
> > > > It's encouraged to provide Acked-bys and Reviewed-bys even though the
> > > > patch has now been applied. If possible patch trailers will be updated.
> > >
> > > Pls don't. Keep it as-is, otherwise there will be merge conflicts
> > > during the merge window.
> >
> > This is just the common blurb. As soon as another part of the tree
> > relies on something we stabilize the branch and only do fixes on top and
> > never rebase. We usually recommend just pulling the branch which I think
> > you did.
> >
> > >
> > > > Note that commit hashes shown below are subject to change due to rebase,
> > > > trailer updates or similar. If in doubt, please check the listed branch.
> > > >
> > > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
> > > > branch: vfs-6.17.bpf
> > > >
> > > > [1/4] kernfs: remove iattr_mutex
> > > >       https://git.kernel.org/vfs/vfs/c/d1f4e9026007
> > > > [2/4] bpf: Introduce bpf_cgroup_read_xattr to read xattr of cgroup's node
> > > >       https://git.kernel.org/vfs/vfs/c/535b070f4a80
> > > > [3/4] bpf: Mark cgroup_subsys_state->cgroup RCU safe
> > > >       https://git.kernel.org/vfs/vfs/c/1504d8c7c702
> > > > [4/4] selftests/bpf: Add tests for bpf_cgroup_read_xattr
> > > >       https://git.kernel.org/vfs/vfs/c/f4fba2d6d282
> > >
> > > Something wrong with this selftest.
> > > Cleanup is not done correctly.
> > >
> > > ./test_progs -t lsm_cgroup
> > > Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED
> > > ./test_progs -t lsm_cgroup
> > > Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED
> > > ./test_progs -t cgroup_xattr
> > > Summary: 1/8 PASSED, 0 SKIPPED, 0 FAILED
> > > ./test_progs -t lsm_cgroup
> > > test_lsm_cgroup_functional:PASS:bind(ETH_P_ALL) 0 nsec
> > > (network_helpers.c:121: errno: Cannot assign requested address) Failed
> > > to bind socket
> > > test_lsm_cgroup_functional:FAIL:start_server unexpected start_server:
> > > actual -1 < expected 0
> > > (network_helpers.c:360: errno: Bad file descriptor) getsockopt(SOL_PROTOCOL)
> > > test_lsm_cgroup_functional:FAIL:connect_to_fd unexpected
> > > connect_to_fd: actual -1 < expected 0
> > > test_lsm_cgroup_functional:FAIL:accept unexpected accept: actual -1 < expected 0
> > > test_lsm_cgroup_functional:FAIL:getsockopt unexpected getsockopt:
> > > actual -1 < expected 0
> > > test_lsm_cgroup_functional:FAIL:sk_priority unexpected sk_priority:
> > > actual 0 != expected 234
> > > ...
> > > Summary: 0/1 PASSED, 0 SKIPPED, 1 FAILED
> > >
> > >
> > > Song,
> > > Please follow up with the fix for selftest.
> > > It will be in bpf-next only.
> >
> > We should put that commit on the shared vfs-6.17.bpf branch.
> 
> The branch had a conflict with bpf-next which was resolved
> in the merge commit. Then _two_ fixes were applied on top.
> And one fix is right where conflict was.
> So it's not possible to apply both fixes to vfs-6.17.bpf.
> 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.

Absolutely not. 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.