Re: [PATCH v6 bpf-next 3/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling

"Kumar Kartikeya Dwivedi" <[email protected]> Fri, 31 Jul 2026 17:44:35 +0200
Newsgroups org.kernel.vger.linux-integrity,org.kernel.vger.bpf,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-security-module,org.kernel.vger.selinux
Message-ID <[email protected]>
On Fri Jul 31, 2026 at 5:30 PM CEST, David Windsor wrote:
> On Fri, Jul 31, 2026 at 11:17=E2=80=AFAM Paul Moore <[email protected]>=
 wrote:
>>
>>
>> Okay, it looks like there was some confusion/misunderstanding.
>>
>> My understanding of Kumar's comments was that he was referring to the
>> exisiting LSM related kfuncs that are located in fs/bpf_fs_kfuncs.c,
>> not necessarily the new kfunc you are proposing in this patchset.
>> Kumar is welcome to correct either one or both of us, if we read that
>> wrong :)
>>
>
> Yes, after another reading, that does appear to be the case =3D).
>
> We'll need v7 anyway to fix the ocfs-related UAF the bot found.
>

Since there is confusion, let me clear it up.

I meant it for all of them. I don't think it makes sense to keep this one i=
n
security/ when others are in fs/bpf_fs_kfuncs.c. That confusing limbo state=
 is
worse than just placing it where others already are.

As I already said, the discussion around whether all of them they should go=
 in
security/ is orthogonal and should be done separately; it isn't productive =
to
repeatedly bring it up in the context of this patch set.

I honestly don't get the urgency; it will be a mechanical change if we need=
 to
make such changes. The worst outcome would be stalling David's work over it=
.

As for landing this stuff, we can let Paul take the patches touching securi=
ty/
and route the rest (3-4) through bpf-next after the merge window. We need t=
hem
to go through BPF CI anyway to ensure nothing breaks.

>> However, regardless of Kumar's intent, speaking as the LSM maintainer,
>> my stance on this is that the kfunc you are proposing must live in
>> security/bpf_lsm_kfuncs.c to be acceptable.
>>
>
> Ack, will do this in v7.
>
> The Landlock series currently up for discussion [1] is proposing
> placing its kfuncs in a new kernel/bpf/bpf_lsm.c. Should these maybe
> go there?
>
> [1] https://lore.kernel.org/bpf/20260731022047.189137-1-utilityemal77@gma=
il.com/
>
>> --
>> paul-moore.com