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: <aWXYi35pu9IHf2eE@stanley.mountain>
Date: Tue, 13 Jan 2026 08:30:51 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: 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

On Mon, Jan 12, 2026 at 04:06:12PM -0800, Dave Hansen wrote:
> +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.
> + - Treat the contribution specially like reviewing with extra scrutiny,
> +   or at a lower priority than human-generated content.
> + - Suggest a better prompt instead of suggesting specific code changes.
> + - Ask for some other special steps, like asking the contributor to
> +   elaborate on how the tool or model was trained.
> + - Ask the submitter to explain in more detail about the contribution
> +   so that the maintainer can be assured that the submitter fully
> +   understands how the code works.
> +
> +If tools permit you to generate a contribution automatically, expect
> +additional scrutiny in proportion to how much of it was generated.
> +
> +As with the output of any tooling, the result may be incorrect or
> +inappropriate. You are expected to understand and to be able to defend
> +everything you submit. If you are unable to do so, then do not submit
> +the resulting changes.
> +
> +If you do so anyway, maintainers are entitled to reject your series
> +without detailed review.

Argh... Flip.  In context, that sounds even more sinister and
threatening than my over the top proposal.  We have to "defend"
everything?  "If you do so anyway" sounds like we're jumping to a
"per my last email" from the get go.  What about:

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.

Ideally, patches would be tested but we understand that that's not
always possible.  Be transparent about how confident we can be that the
changes don't introduce new problems and how they have been tested.

Bug reports especially are very welcome.  Bug reports are more likely
to be dealt with if they can be tied to the individual commit which
introduced them.  With new kinds of warnings, it is better to send
a few at a time at the start to see if they are a real issue or how
they can be improved.

regards,
dan carpenter