linux-kernel - Re: [PATCH] [v5] 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: <69668cfc63bb1_875d1004@dwillia2-mobl4.notmuch>
Date: Tue, 13 Jan 2026 10:20:44 -0800
From: <dan.j.williams@...el.com>
To: Dan Carpenter <dan.carpenter@...aro.org>, 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>, "Paul E . McKenney" <paulmck@...nel.org>, Simon Glass
	<simon.glass@...onical.com>, NeilBrown <neilb@...mail.net>, Lorenzo Stoakes
	<lorenzo.stoakes@...cle.com>, 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] [v5] Documentation: Provide guidelines for tool-generated
 content

Dan Carpenter wrote:
[..]
> If tools permit you to generate a contribution automatically, expect
> additional scrutiny in proportion to how much of it was generated.
> 
> Every kernel patch needs careful review from multiple people.  Please,
> don't start the public review process until after you have carefully
> reviewed the patches yourself.  If you don't have the necessary
> expertise to review kernel code, consider asking for help first before
> sending them to the main list.

Note, I do not want additional changes to this document, my Reviewed-by
still stands with this version, it is good, ship it.

However, I do want to endorse this sentiment as uniquely capturing a
truism of kernel development that perhaps belongs in
Documentation/process/submitting-patches.rst. It captures it in a way
that avoids the conceit of the "slop is special" argument.

Contributions are accepted in large part based in trust in the author.
So much so that even long time contributors self censor, self mistrust,
based on the adage "debugging is harder than developing, if you develop
at the limits of your cleverness you will not be able to debug the
result." Tools potentially allow you to develop beyond the limits of
your own cleverness which implicates the result as "undebuggable" and
unmaintainable.

So a simple rule of "generally you should be able to demonstrate the
ability to substantively review a contribution of similar complexity
before expecting the kernel community to engage in earnest" mitigates
the asymmetric threat of AI contributions *and* contributors that have
not built-up enough trust capital with their upstream maintainer.