linux-kernel - Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content

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: <c04c84a0-c38d-46e3-907d-e32191cfc9f8@lunn.ch>
Date: Thu, 8 Jan 2026 14:41:20 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Dave Hansen <dave@...1.net>, Dave Hansen <dave.hansen@...ux.intel.com>,
	linux-kernel@...r.kernel.org, Shuah Khan <shuah@...nel.org>,
	Kees Cook <kees@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Luis Chamberlain <mcgrof@...nel.org>, SeongJae Park <sj@...nel.org>,
	Dan Williams <dan.j.williams@...el.com>,
	Steven Rostedt <rostedt@...dmis.org>, NeilBrown <neilb@...mail.net>,
	Theodore Ts'o <tytso@....edu>, Sasha Levin <sashal@...nel.org>,
	Jonathan Corbet <corbet@....net>, Vlastimil Babka <vbabka@...e.cz>,
	workflows@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: [PATCH] [v3] Documentation: Provide guidelines for
 tool-generated content

> And it's not like I'm asking for much, I'm not asking you to rewrite the
> document, or take an entirely different approach, I'm just saying that we
> should highlight that :
> 
> 1. LLMs _allow you to send patches end-to-end without expertise_.

As somebody who reviews a lot of networking patches, i already see
lots of human generated patches without expertise. So LLM might
increase the volume of such patches, but the concept itself is not
new, and does not require LLMs.

> 2. As a result, even though the community (rightly) strongly disapproves of
>    blanket dismissals of series, if we suspect AI slop [I think it's useful
>    to actually use that term], maintains can reject it out of hand.

And i do blanket dismiss all but one such patch from an author, and i
try to teach that author how to get that one patch into shape, in the
hope you can learn the processes and apply it to their other
patches. Sometimes the effort works, and you get a new developers
joining the community, sometimes it is a lost cause, and they go away
after having their patches repeatedly rejected.

So i don't think using LLMs makes a difference here. I've seen the
same issue with blindly fixing checkpatch warning, sparse warning,
other static analysis tool warnings. I just see LLMs are another such
tool.

> Point 2 is absolutely a new thing in my view.

And i would disagree with this statement, it is not new, it already
happens.

	Andrew