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: <c9059fe3-24da-4ad5-b098-696040c80122@lucifer.local>
Date: Thu, 8 Jan 2026 11:53:59 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: dan.j.williams@...el.com, 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>, 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 12:43:50PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 8, 2026 at 11:29 AM Lorenzo Stoakes
> <lorenzo.stoakes@...cle.com> wrote:
> >
> > I really don't think it is the case that maintainers can simplly dismiss an
> > entire series like that.
>
> I think Dan was referring to all kinds of series, i.e. maintainers
> have leeway to reject proposals, whether they are big or small and
> whether they are new features or cleanups.

Sure, but I would say it's reasonable that there's a norm in place that
rejecting series outright that aren't _trivially_ dismissable is bad if no
technical objection is given right?

The issue with LLMs is you can generate entirely novel series that aren't
so trivially dimissible but could very well have other signals to hand
e.g. brand new person, never done any kernel work before, sends a bunch of
series at once etc.

So maybe it's worth highlighting this?

>
> After all, the project works by trusting maintainers to do the right
> thing (i.e. the best they can with the information and time at their
> disposal), but sometimes there may not be concrete technical reasons.
>
> For instance, sometimes it is just a matter of bandwidth -- if
> maintainers cannot maintain the code, and no one (that is trusted to
> some degree) is willing to do so, then it would be a bad idea to take
> the code anyway, even if the feature is great, whether LLM-generated
> or not.

Haha well mm does just merge stuff even if there isn't review capacity :)
which I am arguing against presently as a very silly (and unworkable) thing
to do. But that's another debate...

>
> That is also why it is often said that it is a good idea to contact
> maintainers/community before developing completely a new feature etc.
> etc.

Yes, and we've seen in mm people come to the commnuity with a huge new
patchset that is rejected.

But it almost inevitably has _technical feedback_ as part of that reject
that took time, something that the asymmetry of slop wouldn't permit so
cleraly.

>
> So if a subsystem suddenly starts to get an onslaught of series like
> you warn about, then they cannot be expected to review and give
> technical feedback to everything, and they will need to prioritize
> somehow (e.g. fixes), or try to get more maintainers, or raise the
> issue in ksummit, etc.

Right, but we also need to be able to take the sensible approach of simply
not tolerating it.

I mean if the contention is we already in effect can do this, then surely
it's no harm to provide emphasis in the document no?

>
> At least, that is my take, i.e. we need to allow maintainers to adjust
> as things come. And, of course, as a community, we can always reassess
> as conditions change.

See my other point about the tail wags the dog effect when an official
kernel policy document appears to say 'open to business for LLMs'.

Linus has already been quoted in the press I believe with his 'LLMs are
just like any other tool'.

I wish we didn't have to think about that, but we do.

Anyway I'm submitting my suggested delta shortly. It's really not all that
much different from the rest, just putting some emphasis on the slop
aspect.

>
> Cheers,
> Miguel

Thanks, Lorenzo