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: <dfe0ef3b-0569-4849-8ab4-de52276fb053@lucifer.local>
Date: Thu, 8 Jan 2026 13:53:34 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Lunn <andrew@...n.ch>
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

On Thu, Jan 08, 2026 at 02:41:20PM +0100, Andrew Lunn wrote:
> > 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

I mean we all have :)

> increase the volume of such patches, but the concept itself is not
> new, and does not require LLMs.

The difference is the order of magnitude possible. There's a real barrier to
entry for clueless people, and there's a linearity in time taken to generate
submissions.

LLMs don't change the problem, they change the magnitude.

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

Well this is the thing - it varies by subsystem. In mm it's really not like
this.

At any rate, given you disagree - the document suggesting that maintainers
may dismiss out of hand shouldn't be in any way controversial :)

I have submitted an incremental diff to make concrete what I'm suggesting
at [0].

[0]:https://lore.kernel.org/ksummit/611c4a95-cbf2-492c-a991-e54042cf226a@lucifer.local/

>
> 	Andrew

Cheers, Lorenzo