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] [day] [month] [year] [list]

Message-ID: <20260113174408.3fe7497a@gandalf.local.home>
Date: Tue, 13 Jan 2026 17:44:08 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Sasha Levin <sashal@...nel.org>
Cc: dan.j.williams@...el.com, Dan Carpenter <dan.carpenter@...aro.org>, 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>, "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>, 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 Tue, 13 Jan 2026 13:43:14 -0500
Sasha Levin <sashal@...nel.org> wrote:

> >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.

Trust does play a large role here. I get annoyed when someone I never heard
of sends me a patch because a tool told them it was wrong but when looking
at the code, the tool was wrong.

Every so often Dan sends me one of these types of patches because of a
false positive in smatch or something like that. But Dan also sends me
overwhelming more patches that actual fix real bugs. The signal to noise
ratio is rather high with Dan so I never get annoyed from a missed patch
here or there.

But someone I never heard of sending me one of these are totally annoying
as the signal to noise ratio is 0 for them :-p

> >
> >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.  
> 
> Looking at recent history (v6.12..v6.18) we had 1902 authors (a third of
> overall contributors) who contributed a single commit. Out of those 1902, only
> 177 have a Reviewed-by tag pointing to them.
> 
> With a rule like the above, 1700+ contributors would have not been able to send
> their patch in.

But were these all tool submissions?

I also wouldn't expect (or particularly want) new contributors doing
reviews. I think "Reported-by" is a much better metric for new submitters.
I trust people who found real bugs more than people that just slap their
"Reviewed-by" tag on something they probably don't understand.

-- Steve