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

[Kumar Kartikeya Dwivedi]

On Fri Jul 31, 2026 at 6:02 PM CEST, Paul Moore wrote:
> 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.

What "mistakes"? Really? It's just code organization bureaucracy. Calling it a
mistake is just blowing things out of proportion.

I don't think you can simply decide this unilaterally either. Do you take full
responsibility that kfuncs going there won't introduce BPF side regressions? Who
makes sure patches touching the new location run through BPF CI? All of this
needs to be thought through before we decide upon anything.

Thus, I am simply asking you to be reasonable: let's help David make progress,
and get the changes landed. FS, BPF, and LSM folks can then decide on where to
copy paste the existing kfuncs later.

So David, please send the v7 once you've address Sashiko's concern. We are
almost there, and you've been at it for a long time.