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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <93aadf2b-0df4-49eb-91fd-b401b44ce3af@sr71.net>
Date: Wed, 7 Jan 2026 11:18:52 -0800
From: Dave Hansen <dave@...1.net>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>
Cc: 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 1/7/26 10:12, Lorenzo Stoakes 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

:)

Let's look at it another way: What we all *want* for the kernel is
simplicity. Simple rules, simple documentation, simple code. The
simplest way to deal with the LLM onslaught is to pray that our existing
rules will suffice.

For now, I think the existing rules are holding. We have the luxury of
treating LLMs like any other tool. That could change any day because
some new tool comes along that's better at spamming patches at us. I
think that's the point you're trying to make is that the dam might break
any day and we should be prepared for it.

Is that what it boils down to?

>> +As with all contributions, individual maintainers have discretion to
>> +choose how they handle the contribution. For example, they might:
>> +
>> + - Treat it just like any other contribution.
>> + - Reject it outright.
> 
> This is really not correct, it's simply not acceptable in the community to
> reject series outright without justification. Yes perhaps people do that,
> but it's really not something that's accepted.

I'm not quite sure how this gives maintainers a new ability to reject
things without justification, or encourages them to reject
tool-generated code in a new way.

Let's say something generated by "checkpatch.pl --fix" that's trying to
patch arch/x86/foo.c lands in my inbox. I personally think it's OK for
me as a maintainer to say: "No thanks, checkpatch has burned me too many
times in foo.c and I don't trust its output there." To me, that's
rejecting it outright.

Could you explain a bit how this might encourage bad maintainer behavior?