[GIT PULL] BPF changes for 7.4

[Christian Brauner]

On Wed, Oct 21, 2026 at 09:26:56PM -0400, Paul Moore wrote:
> "... just as the maintenence of bpf_fs_funcs.c falls to the VFS." is
> the rest of that sentence.  We're not asking for a type of
> cross-subsystem relationship without precedent.

I love how I always end up in the middle of this somehow. I'm really
trying to be sympathetic to both sides.

> As discussed previously, the kfunc in question isn't really a VFS
> kfunc it's a LSM kfunc populating LSM managed buffers and calling into
> LSM private APIs.

It takes a name in the security.bpf. namespace checks it against
XATTR_NAME_MAX and XATTR_SIZE_MAX, copies the value and fills a struct
xattr that the filesystem's ->initxattrs() callback writes into the
inode it is in the middle of creating.

The LSM part is lsm_get_xattr_slot(), a static inline that hands out the
next entry of an array.

The one problem the series ran into was ocfs2 keeping the name pointer
around after the callback. Which is very much a filesystem contract and
it got sorted out with the ocfs2 maintainers. This is a decent hint
where this code belongs imho.

> One might question the placement of some of the other BPF kfuncs
> located in bpf_fs_kfuncs.c as the file is conditionally built based on
> CONFIG_BPF_LSM as opposed to CONFIG_BPF_SYSCALL or some other generic
> BPF Kconfig knob, but there is no sense in worrying about that until
> we settle this.

The CONFIG_BPF_LSM gate is historical. binfmt_misc BPF programs use
the file as well. It says nothing about who owns the file though.

My view is this:

The lsm framework doesn't own code in other subsystems because it calls
an lsm helper. The same way the vfs doesn't own the lsms simply because
the majority of them live on vfs objects.

I do understand the worry I guess. bpf lsm programs let people build
policy that never shows up on the Lsm list, and kfuncs are ways to build
that policy. For me that's a good thing because it moves a bunch of code
out of the kernel. I understand that it's also something that feels
uncomfortable. It does for me too because I keep worrying "what if we
expose some really broken thing that burns the house down"? But hey, 50%
of kernel development is constant change and 50% is shepherding people
away from the abyss...

--