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

Kumar Kartikeya Dwivedi memxor at gmail.com
Fri Jul 31 18:50:43 UTC 2026


On Fri Jul 31, 2026 at 8:42 PM CEST, Paul Moore wrote:
> On Fri, Jul 31, 2026 at 2:18 PM Kumar Kartikeya Dwivedi
> <memxor at gmail.com> wrote:
>> 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 at 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 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:
>
> ...
>
>> 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.
>
> 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 folks) to
agree on whether placing all such kfuncs there makes sense. It is not for both
of us to decide on our own. So let's revisit this whole topic once you've done
that exercise.



More information about the Linux-security-module-archive mailing list