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

On Fri Jul 31, 2026 at 9:05 PM CEST, Paul Moore wrote:
> On Fri, Jul 31, 2026 at 2:50=E2=80=AFPM Kumar Kartikeya Dwivedi
> <[email protected]> wrote:
>> On Fri Jul 31, 2026 at 8:42 PM CEST, Paul Moore wrote:
>> > On Fri, Jul 31, 2026 at 2:18=E2=80=AFPM Kumar Kartikeya Dwivedi
>> > <[email protected]> wrote:
>> >> On Fri Jul 31, 2026 at 6:59 PM CEST, Paul Moore wrote:
>> >> > On Fri, Jul 31, 2026 at 12:32=E2=80=AFPM Kumar Kartikeya Dwivedi
>> >> > <[email protected]> wrote:
>> >> >> 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 <paul@pau=
l-moore.com> wrote:
>> >
>> > ...
>> >
>> >> Yes, I understand you feel it should be placed under security/. You a=
re entitled
>> >> to your opinion.
>> >>
>> >> No, I do not think the newly added kfunc is a big enough layering vio=
lation such
>> >> that we need to do it ASAP, disregarding everything else outlined abo=
ve. I am
>> >> sure you see that too. There are several other instances of similar k=
funcs.
>> >>
>> >> Therefore, please attempt to meet me halfway here.
>> >
>> > I'm happy to work with you, and/or anyone else, who wants to work on
>> > finding a way to test kfuncs that live in security/bpf_lsm_kfuncs.c.
>>
>> Right, and for that file to exist, you need to get everyone (FS, BPF fol=
ks) to
>> agree on whether placing all such kfuncs there makes sense. It is not fo=
r both
>> of us to decide on our own. So let's revisit this whole topic once you'v=
e done
>> that exercise.
>
> The kfunc that David has proposed must be located in
> security/bpf_lsm_kfuncs.c, similar to the VFS kfuncs and
> fs/bpf_fs_kfuncs.c.  If you read David's bpf_init_inode_xattr() kfunc

Sigh.

I now went and read the archives, and Christian already told you no before =
[0],
which I missed in my first read. So two people whom this code affects alrea=
dy
objected to your proposal.

  [0]: https://lore.kernel.org/bpf/20260625-schnabel-rennmaschine-parieren-=
bcb352c3cf59@brauner

> you will notice there is nothing in the function relating to the VFS,
> well other than the "inode" and "xattr" in the name of the function;

I can also read it the other way. There is only one "security_lsmxattr_add(=
)"
call that is LSM related, and the rest is VFS or BPF specific stuff.

There would be no xattr support in LSM code without filesystems implementin=
g
them.

Please avoid making absurd and non-sensical arguments.

If we went by this logic, we would have to move the entirety of the kernel =
under
security/, since anything that calls into LSM code becomes eligible to go t=
here.

> this is purely a LSM kfunc and I stand by my previous comments.  The
> BPF maintainers have seen fit to decide quite a few things LSM related
> solely on their own, I see no reason why requiring a LSM kfunc be
> located in security/bpf_lsm_kfuncs.c is unreasonable given our current
> situation.
>
> As I said earlier, I'm happy to work with you, David, or anyone else
> on ensuring security/bpf_lsm_kfuncs.c has the proper test coverage,
> but I'm not going to continue to go back and forth about the location
> of the bpf_init_inode_xattr() kfunc that is proposed in this patchset.
> If you, or any of the other BPF maintainers, are not able to live with
> that location then David will need to find another way.

Yeah, I think we've spilled enough ink on this. We'll figure out a way to m=
ove
things forward.  Since VFS people disagree too, the kfunc should stay where=
 it
is in this series.

I am always open to revisiting all this once you can convince others by mak=
ing
useful arguments, instead of imposing your will onto them and throwing a ta=
ntrum.