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: <9afd157a-296d-4f4d-9d65-07b89ab3906f@redhat.com>
Date: Mon, 28 Jul 2025 11:27:48 +0200
From: David Hildenbrand <david@...hat.com>
To: Vlastimil Babka <vbabka@...e.cz>, Sasha Levin <sashal@...nel.org>,
 corbet@....net, linux-doc@...r.kernel.org, workflows@...r.kernel.org
Cc: josh@...htriplett.org, kees@...nel.org, konstantin@...uxfoundation.org,
 linux-kernel@...r.kernel.org, rostedt@...dmis.org
Subject: Re: [PATCH 0/4] Add agent coding assistant configuration to Linux
 kernel

On 28.07.25 09:58, Vlastimil Babka wrote:
> On 7/27/25 21:57, Sasha Levin wrote:
>> This patch series adds unified configuration and documentation for coding
>> agents working with the Linux kernel codebase. As coding agents
>> become increasingly common in software development, it's important to
>> establish clear guidelines for their use in kernel development.
> 
> Hi,
> 
> this series seems to me somewhat premature. I think we first need a clear
> policy wrt LLM usage for the *humans* to follow. It seemed this thread [1]
> was going into that direction wrt usage disclosure. BTW I was quite shocked
> by Steven's reply there [2] that he learned from the LWN coverage of a
> conference talk that he had received a patch fully written by LLM without
> any such indication. Now I'm not naive to believe that it's not been
> happening already from e.g. first-time contributors, but if that coverage
> was accurate, the patch came from a very seasoned kernel contributor and I
> really wouldn't expect that to happen.
> 
> Also I don't know e.g. the copyright and licensing implications of LLM usage
> beyond, say, a smarter automplete are clear? (again, such as writing the
> full patch?) The thread [1] touched on it somewhat but not completely. If
> that's clear already (IANAL), I'd hope that to be also part of such policy.
> 
> I know that your series has patch 4, but that seems to be part of what the
> LLM is supposed to include for its prompt (does it make sense to call it
> "legal requirements" then?). If it fails to e.g. add the "Co-developed-by:"
> there seems to be nothing saying the human should check these things in the
> output.

Exactly that.

I want to have it clearly spelled out that if you're submitting AI 
generated code that you don't fully understand and have reviewed in 
detail, then you are going to have a real bad time around here.

I don't have time to talk to an AI chatbot through mail when reviewing 
patches, because the submitter doesn't understand what he is doing and 
blindly copy-pastes my replies to the AI.

This must not be the new mechanism to DoS kernel maintainers with AI slop.

I'll point at the approach qemu[1] has taken, which is probably a bit 
too strict, but raises some key points regarding DCO, copyright etc.

[1] 
https://github.com/qemu/qemu/commit/3d40db0efc22520fa6c399cf73960dced423b048

-- 
Cheers,

David / dhildenb