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: <cfb8bb96-e798-474d-bc6f-9cf610fe720f@lucifer.local>
Date: Fri, 9 Jan 2026 07:48:35 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Dave Hansen <dave@...1.net>, Dave Hansen <dave.hansen@...el.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        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>,
        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, Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH] [v3] Documentation: Provide guidelines for
 tool-generated content

+cc Jens as reference him

On Thu, Jan 08, 2026 at 03:14:37PM -0500, Steven Rostedt wrote:
> On Thu, 8 Jan 2026 11:50:29 -0800
> Dave Hansen <dave@...1.net> wrote:
>
> > On 1/8/26 11:23, Lorenzo Stoakes wrote:
> > > 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.
> >
> > The reason I resisted integrating this is it tries to draw too specific
> > a line in the sand. Someone could rightfully read that and say they
> > don't expect additional scrutiny because the entire series was not
> > automatically generated.

I mean you are making an absolutely valid point, I'd say that'd be a rather
silly conclusion to take, but we have to be wary of 'lawyering' the doc
here.

> >
> > What I want to say is: the more automation your tool provides, the more
> > scrutiny you get. Maybe:
> >
> > 	Expect increasing amounts of maintainer scrutiny on
> > 	contributions that were increasingly generated by tooling.
>
> Honestly that just sounds "grumpy" to me ;-)
>
> How about something like:
>
> 	All tooling is prone to make mistakes that differ from mistakes
> 	generated by humans. A maintainer may push back harder on
> 	submissions that were entirely or partially generated by tooling
> 	and expect the submitter to demonstrate that even the generated
> 	code was verified to be accurate.
>
> -- Steve

I don't really read that as grumpy, I understand wanting to be agreeable
but sometimes it's appropriate to be emphatic, which is the entire purpose
of this amendment.

Taking into account Jens's input too:

+If tools permit you to generate series automatically, expect
+additional scrutiny in proportion to how much of it was generated.
+
+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, then don't submit the
+resulting changes.
+
+If you do so anyway, maintainers are entitled to reject your series without
+detailed review.

Does this work?

As per Dan later in this thread I do truly wish we could have (yes in all
caps) 'NO SLOP PLEASE'. But I am compromising on that ;)

Cheers, Lorenzo