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

[Paul Moore]

On Fri, Jul 31, 2026 at 11:44 AM Kumar Kartikeya Dwivedi
<memxor at gmail.com> wrote:
> On Fri Jul 31, 2026 at 5:30 PM CEST, David Windsor wrote:
> > On Fri, Jul 31, 2026 at 11:17 AM Paul Moore <paul at paul-moore.com> 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 =).
> >
> > 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 in
> 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 security/
> and route the rest (3-4) through bpf-next after the merge window. We need them
> to go through BPF CI anyway to ensure nothing breaks.

Some existing LSM kfuncs are located in the wrong files.  I'm not
suggesting that David needs to fix the existing problems, but there is
no reason to keep making the same mistakes.  The new LSM kfunc must go
in security/bpf_lsm_kfuncs.c; if that isn't acceptable to the BPF
developers then David will need to find a new way that doesn't involve
kfuncs.

-- 
paul-moore.com