linux-kernel - Re: [PATCH 0/4] Add agent coding assistant configuration to Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aIdw3-G04QQPvJtU@lappy>
Date: Mon, 28 Jul 2025 08:45:19 -0400
From: Sasha Levin <sashal@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Greg KH <greg@...ah.com>, corbet@....net, linux-doc@...r.kernel.org,
	workflows@...r.kernel.org, josh@...htriplett.org, kees@...nel.org,
	konstantin@...uxfoundation.org, linux-kernel@...r.kernel.org,
	rostedt@...dmis.org, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 0/4] Add agent coding assistant configuration to Linux
 kernel

On Mon, Jul 28, 2025 at 11:52:47AM +0100, Lorenzo Stoakes wrote:
>One thing to note is that I struggled to get an LLM to read MAINTAINERS
>properly recently (it assured me, with absolute confidence, that the SLAB
>ALLOCATOR section was in fact 'SLAB ALLOCATORS' + provided me with
>completely incorrect contents, and told me that if I didn't believe it I
>should go check :)

Heh, I wouldn't trust LLM with anything more than mechanical
transformations or test writing at this point :)

>So at all times I think ensuring the human element is aware that they need
>to do some kind of checking/filtering is key.
>
>But that can be handled by a carefully worded policy document.

Right. The prupose of this series is not to create a new LLM policy but
rather try and enforce our existing set of policies on LLMs.

Right now the "official" policy of our project is that we accept agent
generated contributions without any requirements beyond what applies to
regular humans, which most LLMs promptly skip reading and go do their
own thing...

So I wanted to at least force LLMs to go RTFM before writing code.

>>
>> > In addition, it's concerning that we're explicitly adding configs for
>> > specific, commercial, products. This might be seen as an endorsement
>> > whether intended or not.
>>
>> Don't we already have that for a few things already, like .editorconfig?
>
>Right, but I think it's a whole other level when it's a subscription
>service. I realise we have to be practical, but it's just something to be
>aware of.
>
>Perhaps an entry in the AI doc along the lines of 'provision of
>configuration for a service is not advocating for that service, it is
>simply provided for convenience' or similar might help.

It also gives us the option of dropping some of these if we find them to
be either horrible at their job or just being abused.

-- 
Thanks,
Sasha