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: <99b046ce-3f91-4fb8-bd15-9045cc35f7e9@lucifer.local>
Date: Thu, 8 Jan 2026 10:03:15 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Linus Torvalds <torvalds@...ux-foundation.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,
        Chris Mason <clm@...a.com>
Subject: Re: [PATCH] [v3] Documentation: Provide guidelines for
 tool-generated content

+cc Chris as I mention him :)

On Wed, Jan 07, 2026 at 04:06:35PM -0800, Linus Torvalds wrote:
> On Wed, 7 Jan 2026 at 13:20, Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> >
> > Thinking LLMs are 'just another tool' is to say effectively that the kernel
> > is immune from this. Which seems to me a silly position.
>
> No. Your position is the silly one.
>
> There is *zero* point in talking about AI slop. That's just plain stupid.
>
> Why? Because the AI slop people aren't going to document their patches
> as such. That's such an obvious truism that I don't understand why
> anybody even brings up AI slop.

The point is:

a. For the tech press to not gleefully report that the kernel just accepts AI
   patches now since hey it's just another tool.

b. To be able to refer back to the document when rejecting series.

As to point a., as I said before in other threads, I remain concerned that
the second the tech press say 'the kernel accepts AI patches now' we'll see
an influx.

It's sad we have to think about that, but it's a fact of life.

>
> So stop this idiocy.
>
> The documentation is for good actors, and pretending anything else is
> pointless posturing.

I mean with respect, if the document is saying in effect 'hey everything's
the same relax', what's the point of the document again?

>
> As I said in private elsewhere, I do *not* want any kernel development
> documentation to be some AI statement. We have enough people on both
> sides of the "sky is falling" and "it's going to revolutionize
> software engineering", I don't want some kernel development docs to
> take either stance.

To be clear I am actually quite optimistic about AI tooling in some areas,
most notably review (Chris Mason is doing some great work on this for
instance! :)

My suggestions are _not_ taking either position.

They are just there to address points a and b above, while otherwise
retaining the same exact position as the document currently does.

(I actually feel the rest of the document is good, as I said in v1 review,
Dave + of course the other reviewers did a good job.)

>
> It's why I strongly want this to be that "just a tool" statement.
>
> And the AI slop issue is *NOT* going to be solved with documentation,
> and anybody who thinks it is either just naive, or wants to "make a
> statement".

I mean, not sure I said we'd be solving AI slop here :) if we could solve
it with a document that'd be great, but I'm not that naive/hopeful
obviously.

Dave asked me to send an incremental patch to the documentation to be
entirely clear as to what change I'm suggesting, I am happy to do that
FWIW.

Perhaps that'll make my suggestion a little clearer.

>
> Neither of which is a good reason for documentation.
>
>              Linus

Thanks, Lorenzo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ