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

[Kumar Kartikeya Dwivedi]

On Sat Aug 1, 2026 at 12:27 AM CEST, Casey Schaufler wrote:
> On 7/31/2026 3:04 PM, Kumar Kartikeya Dwivedi wrote:
>> On Fri Jul 31, 2026 at 11:49 PM CEST, Paul Moore wrote:
>>> On Fri, Jul 31, 2026 at 5:29 PM Kumar Kartikeya Dwivedi
>>> <memxor at gmail.com> wrote:
>>>> On Fri Jul 31, 2026 at 10:48 PM CEST, Paul Moore wrote:
>>>>> On Fri, Jul 31, 2026 at 4:16 PM Kumar Kartikeya Dwivedi
>>>>> <memxor at gmail.com> wrote:
>>>>>> On Fri Jul 31, 2026 at 10:01 PM CEST, Paul Moore wrote:
>>>>>>> On Fri, Jul 31, 2026 at 3:20 PM Kumar Kartikeya Dwivedi
>>>>>>> <memxor at gmail.com> wrote:
>>>>>>>> On Fri Jul 31, 2026 at 9:05 PM CEST, Paul Moore wrote:
>>>>>>>>> On Fri, Jul 31, 2026 at 2:50 PM Kumar Kartikeya Dwivedi
>>>>>>>>> <memxor at gmail.com> wrote:
>>>>>>>>>> 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:
>>> ...
>>>
>>>> I think you keep forgetting that you cannot unilaterally decide this. Both VFS
>>>> and BPF people have told you that it does not make sense. What was clearly LSM
>>>> specific code has been moved under security/ already.
>>> I'm charged with doing the Right Thing for the LSM framework, and in
>>> my opinion it is in the best interest of the LSM framework that the
>>> kfunc being proposed lives in security/bpf_lsm_kfuncs.c, just as the
>>> VFS kfuncs live in fs/bpf_fs_kfuncs.c.
>>>
>> I think the "Right Thing" would be caring about your users and the project
>> moving forward, who want this functionality, and figuring out the best way to
>> make it happen while working collaboratively with others. Life is full of
>> tradeoffs.
>
> It certainly is. Paul has taken a stance that supports the ongoing maintenance
> of the LSM subsystem. It does not have a stable API in support of the rapid
> development of Linux kernel features *outside of* the LSM infrastructure. That is,
> people like you. If LSM hook implementations were spread throughout the kernel
> code it would be much more difficult for poor hobbyist LSM developers like me
> to track them down when making changes. Changes like the ones you require.

I would recommend reading the patches before commenting. All LSM code is under
security/ (patch 2), as it should be.

> This is about being able to continue supporting the latest and greatest additions
> to the system. Like yours, io_uring and the network protocol d'jour.
>

I don't know what you're on about.

> Please don't lecture us on collaboration and trade-offs. We live and breath that.
>

Paul is free to take a stance for LSM code, just like the BPF maintainers get to
decide on where BPF related code should live. I'm sure you know that.

Thus, please avoid justifying his overreach on where others maintainers should
keep their code.