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: <9de93bf7-80ee-4a50-b8e5-cc8d6e25bd78@lucifer.local>
Date: Thu, 8 Jan 2026 10:40:31 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Dirk Hohndel <dirk@...ndel.org>
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 Wed, Jan 07, 2026 at 01:37:04PM -0800, Dirk Hohndel wrote:
>
>
> > On Jan 7, 2026, at 13:15, Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> >
> > On Wed, Jan 07, 2026 at 11:18:52AM -0800, Dave Hansen wrote:
> >> ...
> >>> I know Linus had the cute interpretation of it 'just being another tool'
> >>> but never before have people been able to do this.
> >>
> >> I respect your position here. But I'm not sure how to reconcile:
> >>
> >> 	LLMs are just another tool
> >> and
> >> 	LLMs are not just another tool
> >>
> >> :)
> >
> > Well I'm not asking you to reconcile that, I'm providing my point of view
> > which disagrees with the first position and makes a case for the
> > second. Isn't review about feedback both positive and negative?
> >
> > Obviously if this was intended to simply inform the community of the
> > committee's decision then apologies for misinterpreting it.
> >
> > I would simply argue that LLMs are not another tool on the basis of the
> > drastic negative impact its had in very many areas, for which you need only
> > take a cursory glance at the world to observe.
> >
> > Thinking LLMs are 'just another tool' is to say effectively that the kernel
> > is immune from this. Which seems to me a silly position.
>
> I think Linus' position is based on what the LLM does when it comes to writing
> code. Your position is based on the impact that LLMs have when it comes to
> 'regular' maintainers (since he ignores GitHub PRs and only takes merge requests
> sent directly to him, I don't think he ever sees just how much garbage gets sent
> to maintainers...)

Yes, absolutely.

>
> >> For now, I think the existing rules are holding. We have the luxury of
> >
> > We're noticing a lot more LLM slop than we used to. It is becoming more and
> > more of an issue.
>
> The kernel isn't alone in getting garbage PRs, but I think for the kernel the initial
> hurdle to creating a PR was bigger than for most other projects, so the sudden
> increase in slop is likely felt even more.

Absolutely. This is exactly the problem. And LLMs uniquely enable people to send
these end-to-end. This is why they are different from previous tools.

>
> > 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_.
> >
> > 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.
> >
> > Point 2 is absolutely a new thing in my view.
>
> And as much as I respect the desire to be open to new tools and to encourage
> new developers, I think this statement is very much on point and useful to
> include.
> (of course, my opinion isn't all that relevant, given how long it has been that
> I have sent kernel merge requests)

Thanks :)

Well I don't send any merge requests to Linus direct myself as a sub-maintainer
in mm ;) so if that were the criteria I'd fail on that also! :)

>
> /D
>

Cheers, Lorenzo