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

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Fri Jul 31, 2026 at 6:59 PM CEST, Paul Moore wrote:
> On Fri, Jul 31, 2026 at 12:32 PM Kumar Kartikeya Dwivedi
> <memxor@gmail.com> wrote:
>> 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@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@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.
>
>  :D
>
> You've no doubt seen the challenging interactions between some of the
> BPF and LSM developers over the past several years.  A recent BPF LSM
> bug/vulnerability as well as these interactions between the BPF/LSM
> devs, has caused me to take a much closer look at how things have been
> done regarding the BPF LSM and there are a number of things that
> should be addressed.  Not all of those things will be addressed now,
> but I won't support patches that continue to do things the wrong way
> because I currently have very little faith in our ability to correct
> them later.

I am not sure whether you shared whatever concerns you are talking about.  If
they are valid, we would be happy to engage and resolve them.

I am aware of the past discussions, but we did spend additional effort to find a
way that worked well for everyone in the end.

> I do hope that at some time in the future we can reach a
> point where there is more cooperation between the two communities, but
> given the recent difficulties over even the small things, we are not
> there yet.
>

I think it takes two hands to clap.

So far, I have tried to engage constructively, and offered to discuss where
these kfuncs collectively should stay in a separate discussion. Explained why it
cannot be done unilaterally, and that we need consensus from all stakeholders
(FS, BPF, LSM). Explained that we need to figure out how the testing strategy
for such cross-cutting changes would work if they don't go through BPF tree.

In response, I have only seen you continually tried to derail the whole thing
over the location of the kfunc, threatening to not let it move forward.

Yes, I understand you feel it should be placed under security/. You are entitled
to your opinion.

No, I do not think the newly added kfunc is a big enough layering violation such
that we need to do it ASAP, disregarding everything else outlined above. I am
sure you see that too. There are several other instances of similar kfuncs.

Therefore, please attempt to meet me halfway here.

It is calling a single security_lsmxattr_add() kfunc cleanly abstracted and
already placed under security/, where it belongs.

>> 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.
>
> I would expect, and require, that patch submitters perform the
> necessary testing for the patches they submit; this is no different
> from any other patch today that is submitted for the LSM framework.

It doesn't scale. The amount of combinations (architectures x compilers x modes)
that need to be tested for the BPF subsystem is beyond reasonable for any patch
submitter to test themselves. The only realistic approach is letting it go
through BPF CI and exercising the full matrix on submission.

It is fairly apparent to me that you do not have a clear picture how BPF code
gets tested (which is fine and understandable).

It only underscores my point: we need to move this discussion elsewhere, and
have a broader dialogue and form consensus. Not litigate over it in this thread.

David spent considerable effort on this set, and has carefully reworked his code
several times. Blocking his work over this terriotrial argument would be a loss
for everyone, including the users of the kernel.

Anyhow, I cannot stop you, but it would be unfortunate if you continue to double
down, in that case we'll have to figure out other ways of moving things forward.

> [...]