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

[Kees Cook <kees@kernel.org>]

On Wed, Jul 30, 2025 at 05:59:25PM +0100, Lorenzo Stoakes wrote:
> On Wed, Jul 30, 2025 at 12:36:25PM -0400, Sasha Levin wrote:
> > Some sort of a "traffic light" system:
> >
> >  1. Green: the subsystem is happy to receive patches from any source.
> >
> >  2. Yellow: "If you're unfamiliar with the subsystem and using any
> >  tooling to generate your patches, please have a reviewed-by from a
> >  trusted developer before sending your patch".
> >
> >  3. No tool-generated patches without prior maintainer approval.
> 
> This sounds good, with a default on red. Which would enforce the opt-in
> part.

This is way too draconian. The human is still responsible for sending
patches -- their reputation is on the line if things go badly.

I think we can capture the essence of "don't send bad patches, regardless
of tool" without saying "if you use this class of tool, you are banned
from sending anything that it helped you with." That's not useful,
realistic, nor enforceable.

I get a sense that many people in this thread haven't actually used
these tools themselves. It requires active management like anything else:
Coccinelle isn't going to get things 100% right based on your first stab
at a script. Neither is an LLM. It still requires the human to DTRT. And
just as some examples, here are my LLM assisted patches so far:

https://lore.kernel.org/lkml/20250717085156.work.363-kees@kernel.org/
https://lore.kernel.org/lkml/20250724030233.work.486-kees@kernel.org/
https://lore.kernel.org/lkml/20250724080756.work.741-kees@kernel.org/

Even the latter I had to walk it through the analysis and suggest a style
edit. With the KUnit tests, I had to do significant editing/adjustment/etc
to all of these.

-- 
Kees Cook