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

On 7/31/2026 3:45 PM, Kumar Kartikeya Dwivedi wrote:
> 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
>>>> <[email protected]> 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
>>>>>> <[email protected]> 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
>>>>>>>> <[email protected]> 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
>>>>>>>>>> <[email protected]> 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
>>>>>>>>>>>> <[email protected]> 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
>>>>>>>>>>>>>> <[email protected]> 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
>>>>>>>>>>>>>>>> <[email protected]> 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 <[email protected]> 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.

Pa-lease. I have in fact read the patch. I disagree with you assessment.

>> 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.

I have been developing kernel code since the 1970's (UNIX and Linux) and have
a fair bit of understanding about source code organization. Without rational
layering and co-location chaos ensues. The BPF developers are newbies relative
to the security maintainers, and would do well to pay some attention to the
wisdom of the aged.