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

On Fri Jul 31, 2026 at 6:02 PM CEST, Paul Moore wrote:
> On Fri, Jul 31, 2026 at 11:44=E2=80=AFAM Kumar Kartikeya Dwivedi
> <[email protected]> wrote:
>> 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]=
om> 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 on=
e in
>> security/ when others are in fs/bpf_fs_kfuncs.c. That confusing limbo st=
ate 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 producti=
ve 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 n=
eed 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 sec=
urity/
>> and route the rest (3-4) through bpf-next after the merge window. We nee=
d 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 i=
t a
mistake is just blowing things out of proportion.

I don't think you can simply decide this unilaterally either. Do you take f=
ull
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 thi=
s
needs to be thought through before we decide upon anything.

Thus, I am simply asking you to be reasonable: let's help David make progre=
ss,
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.