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: <aWCSVh6NocePMvp8@stanley.mountain>
Date: Fri, 9 Jan 2026 08:29:58 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>
Cc: Jens Axboe <axboe@...nel.dk>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Dave Hansen <dave.hansen@...el.com>,
	James Bottomley <James.Bottomley@...senpartnership.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>,
	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 Thu, Jan 08, 2026 at 04:04:39PM -0500, Liam R. Howlett wrote:
> * Jens Axboe <axboe@...nel.dk> [260108 15:54]:
> > On 1/8/26 12:23 PM, Lorenzo Stoakes wrote:
> > >> @@ -95,3 +95,8 @@ choose how they handle the contribution. For example, they might:
> > >>   - Ask the submitter to explain in more detail about the contribution
> > >>     so that the maintainer can feel comfortable that the submitter fully
> > >>     understands how the code works.
> > >> +
> > >> +Finally, always be prepared for tooling that produces incorrect or
> > >> +inappropriate content. Make sure you understand and to be able to
> > >> +defend everything you submit. If you are unable to do so, maintainers
> > >> +may choose to reject your series outright.
> > >>
> > > 
> > > I feel like this formulation waters it down so much as to lose the emphasis
> > > which was the entire point of it.
> > > 
> > > I'm also not sure why we're losing the scrutiny part?
> > > 
> > > Something like:
> > > 
> > > +If tools permit you to generate series entirely automatically, expect
> > > +additional scrutiny.
> > > +
> > > +As with the output of any tooling, the result maybe incorrect or
> > > +inappropriate, so you are expected to understand and to be able to defend
> > > +everything you submit. If you are unable to do so, maintainers may choose
> > > +to reject your series outright.
> > 
> > Eh, why not some variant of:
> > 
> > "If you are unable to do so, then don't submit the resulting changes."
> > 
> > Talking only for myself, I have ZERO interest in receiving code from
> > someone that doesn't even understand what it does. And it'd be better to
> > NOT waste my or anyone elses time if that's the level of the submission.
> 
> Yes, agreed.
> 

Yeah.  Me too.

> If I cannot understand it and the author is clueless about the patch,
> then I'm going to be way more grumpy than the wording of that statement.
> 
> I'd assume the submitter would just get the ai to answer it anyways
> since that's fitting with the level of the submission.

Yes.  That has happened to me.  I asked the submitter how do you know
this is true? And the v2 had a long AI generated explanation which quoted
a spec from an AI hallucination.

I like Dave's document but the first paragraph should be to not send AI
slop.

regards,
dan carpenter