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: <0b9a8f99-5cc4-40e8-a0e6-4887d1e1a796@lucifer.local>
Date: Fri, 9 Jan 2026 07:54:31 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>, Jens Axboe <axboe@...nel.dk>,
        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 Fri, Jan 09, 2026 at 08:29:58AM +0300, Dan Carpenter wrote:
> 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.

This is the entire point of my push back here :)

I'd prefer us to be truly emphatic with a 'NO SLOP PLEASE' as the opener and
using that term, but I'm compromising because... well you saw Linus's position
right?

I do find it... naive to think that we won't experience this. For one it's
already started, for another people working on open source projects like
Postgres may have something to say e.g. [0]...

[0]:https://mastodon.social/@AndresFreundTec/115860496055796941

Do we really want to provide a milquetoast document that is lovely and agreeable
and reading it doesn't explicitly say no slop that _will_ be reported on like that?

Note that Linus's position on this has been reported as essentially 'Linus says
AI tools are like other tools and you are STUPID if you think otherwise they are
FINE' - which is not what he said, but does that matter?

Do we really truly think doing that is going to have no impact on people sending
us crap? There are a bunch of well-meaning but less-talented people who try to
do kernel stuff, we've all seen it and dealt with it. These same people _will_
pay attention to this kind of thing and try it on.

Yes we can't do anything about bad faith people who'll ignore everything. But in
that case being able to point at the doc will make life practically _easier_.

Either way I think it's important we have something vaguely emphatic there.

Which is why I'm tiring myself out with this thread when I have a lot of other
things to do :)

>
> regards,
> dan carpenter
>

Cheers, Lorenzo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ