* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-09 11:25 UTC (permalink / raw)
To: Dan Carpenter
Cc: Steven Rostedt, Dave Hansen, Dave Hansen, James Bottomley,
Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, NeilBrown, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit, Jens Axboe
In-Reply-To: <aWDf1zlLTKmw9xnq@stanley.mountain>
On Fri, Jan 09, 2026 at 02:00:39PM +0300, Dan Carpenter wrote:
> On Fri, Jan 09, 2026 at 07:48:35AM +0000, Lorenzo Stoakes wrote:
> > +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@sr71.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.
>
> This is too subtle. In real life if we suspect a patchset is AI Slop,
> then we're going to reject the whole thing immediately. No one is
> going to review all fifteen patches one by one as if we're searching
> through monkey poo for edible grains of corn.
I'm trying to compromise as the general direction on this document is to be
very soft (see the suggested edits so far).
I get why, but the entire purpose of this amendment is to put emphasis and
really to stand up as a community and to say clearly this isn't something
we want.
>
> The AI slop patches I've seen were not bad actors. Someone saw a
> TODO in the file and thought that AI could solve it. The patch
> compiled, it was formatted correctly and the commit message sounded
> confident so they sent it.
Yes exactly this. Exactly.
I've said it elsewhere, but:
a. People who have good intentions who will take this as a green light to
just send out fully LLM generated stuff.
b. Press coverage (it's already happening) will essentially signal it's a
green light on this.
For e.g.:
https://www.phoronix.com/news/Torvalds-Linux-Kernel-AI-Slop
https://www.theregister.com/2026/01/08/linus_versus_llms_ai_slop_docs/?td=rt-3a
>
> To me the audience for this is maybe a team working on AI and they
> don't have any kernel developers on staff so they assume they're being
> helpful sending unreviewed patches. The message should be that every
> patch needs to be reviewed carefully before it is sent upstream. I've
> been asked to review patches like this in the past. Get outside help
> if you need to, but every patch needs to be reviewed.
Yes exactly.
But also it's useful when dealing even with bad actors to point at the
community _actually taking a postiion_.
And frankly on waiting for it to 'get worse' (i.e. to get like basically
the rest of open source) - I have little faith the document really will be
updated to say anything forthright at least at any speed, and by then it'll
be too little too late.
The idea the kernel community taking a position doesn't have any impact is
simply false.
I think far too much thinking in terms of how computers are going on here,
and too little about how people are.
>
> regards,
> dan carpenter
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dan Carpenter @ 2026-01-09 11:00 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Steven Rostedt, Dave Hansen, Dave Hansen, James Bottomley,
Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, NeilBrown, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit, Jens Axboe
In-Reply-To: <cfb8bb96-e798-474d-bc6f-9cf610fe720f@lucifer.local>
On Fri, Jan 09, 2026 at 07:48:35AM +0000, Lorenzo Stoakes wrote:
> +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@sr71.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.
This is too subtle. In real life if we suspect a patchset is AI Slop,
then we're going to reject the whole thing immediately. No one is
going to review all fifteen patches one by one as if we're searching
through monkey poo for edible grains of corn.
The AI slop patches I've seen were not bad actors. Someone saw a
TODO in the file and thought that AI could solve it. The patch
compiled, it was formatted correctly and the commit message sounded
confident so they sent it.
To me the audience for this is maybe a team working on AI and they
don't have any kernel developers on staff so they assume they're being
helpful sending unreviewed patches. The message should be that every
patch needs to be reviewed carefully before it is sent upstream. I've
been asked to review patches like this in the past. Get outside help
if you need to, but every patch needs to be reviewed.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Laurent Pinchart @ 2026-01-09 8:54 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Dan Carpenter, Liam R. Howlett, Jens Axboe, Dave Hansen,
James Bottomley, Dave Hansen, Dave Hansen, linux-kernel,
Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Luis Chamberlain, SeongJae Park, Dan Williams, Steven Rostedt,
NeilBrown, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <0b9a8f99-5cc4-40e8-a0e6-4887d1e1a796@lucifer.local>
On Fri, Jan 09, 2026 at 07:54:31AM +0000, Lorenzo Stoakes wrote:
> 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@kernel.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 :)
Thank you for that. As a lurker in this mail thread, I really appreciate
your efforts as they're saving the time I would need to argue as
strongly as you do :-)
While I agree with the argument that kernel documentation should not
cover every single hypothetical case that one could come up with, the
issue at hand here is real (based on the multiple people who have
replied saying they have seen it happen), and I don't think anyone
expects the problem to disappear magically given the industry trend.
It is also absolutely true that actors with questionable ethics will not
care about the documentation. I do see value in being able to point
developers acting in good faith to the rules, but an even more important
point in my opinion is the message your proposal gives to maintainers.
On a side note, I wonder if this is symptomatic of an erosion of trust
in this conflictual world, with some maintainers increasingly fearing
they will be forced or overridden.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-09 7:54 UTC (permalink / raw)
To: Dan Carpenter
Cc: Liam R. Howlett, Jens Axboe, Dave Hansen, James Bottomley,
Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, NeilBrown, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <aWCSVh6NocePMvp8@stanley.mountain>
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@kernel.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
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-09 7:48 UTC (permalink / raw)
To: Steven Rostedt
Cc: Dave Hansen, Dave Hansen, James Bottomley, Dave Hansen,
linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
NeilBrown, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit, Jens Axboe
In-Reply-To: <20260108151437.3188cd53@gandalf.local.home>
+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@sr71.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
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-09 7:28 UTC (permalink / raw)
To: Dan Carpenter
Cc: Steven Rostedt, Dave Hansen, Dave Hansen, James Bottomley,
Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, NeilBrown, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <aWCVYLuUFZrsbfd-@stanley.mountain>
On Fri, Jan 09, 2026 at 08:42:56AM +0300, Dan Carpenter wrote:
> 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@sr71.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.
> > >
> > > 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
>
> It's better to have a grumpy document, instead of grumpy emails. We
> need it to sound grumpy and it needs to be the first paragraph.
>
> AI Slop: AI can generate a ton of patches automatically which creates a
> burden on the upstream maintainers. The maintainers need to review
> every line of every patch and they expect the submitters to demonstrate
> that even the generated code was verified to be accurate. If you are
> unsure of whether a patch is appropriate then do not send it. NO AI
> SLOP!
>
> Of course, sensible people don't need to be told this stuff, but there
> are well intentioned people who need it explained.
>
> regards,
> dan carpenter
>
Exactly.
Every version of watering it down just makes it meaningless noise. The point is
to emphasise this.
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dan Carpenter @ 2026-01-09 5:42 UTC (permalink / raw)
To: Steven Rostedt
Cc: Dave Hansen, Lorenzo Stoakes, Dave Hansen, James Bottomley,
Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, NeilBrown, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260108151437.3188cd53@gandalf.local.home>
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@sr71.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.
> >
> > 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
It's better to have a grumpy document, instead of grumpy emails. We
need it to sound grumpy and it needs to be the first paragraph.
AI Slop: AI can generate a ton of patches automatically which creates a
burden on the upstream maintainers. The maintainers need to review
every line of every patch and they expect the submitters to demonstrate
that even the generated code was verified to be accurate. If you are
unsure of whether a patch is appropriate then do not send it. NO AI
SLOP!
Of course, sensible people don't need to be told this stuff, but there
are well intentioned people who need it explained.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dan Carpenter @ 2026-01-09 5:29 UTC (permalink / raw)
To: Liam R. Howlett
Cc: Jens Axboe, Lorenzo Stoakes, Dave Hansen, James Bottomley,
Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, NeilBrown, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <3xf3f4b3vegssexoid746y7isuswwsgmac5hy2hm4ipisdcxaf@nbi67byycwj5>
On Thu, Jan 08, 2026 at 04:04:39PM -0500, Liam R. Howlett wrote:
> * Jens Axboe <axboe@kernel.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
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Liam R. Howlett @ 2026-01-08 21:04 UTC (permalink / raw)
To: Jens Axboe
Cc: Lorenzo Stoakes, Dave Hansen, James Bottomley, Dave Hansen,
Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, NeilBrown, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <711d9e37-6fe7-4783-8ac4-5269279bb9fe@kernel.dk>
* Jens Axboe <axboe@kernel.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.
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.
Thanks,
Liam
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Jens Axboe @ 2026-01-08 20:45 UTC (permalink / raw)
To: Lorenzo Stoakes, Dave Hansen
Cc: James Bottomley, Dave Hansen, Dave Hansen, linux-kernel,
Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Luis Chamberlain, SeongJae Park, Dan Williams, Steven Rostedt,
NeilBrown, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <f93a5311-4689-486b-aea8-261263f4d447@lucifer.local>
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.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-08 20:14 UTC (permalink / raw)
To: Dave Hansen
Cc: Lorenzo Stoakes, Dave Hansen, James Bottomley, Dave Hansen,
linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
NeilBrown, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <5a301272-31ea-44b8-9518-8151edca6c06@sr71.net>
On Thu, 8 Jan 2026 11:50:29 -0800
Dave Hansen <dave@sr71.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.
>
> 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
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2026-01-08 19:50 UTC (permalink / raw)
To: Lorenzo Stoakes, Dave Hansen
Cc: James Bottomley, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, NeilBrown, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <f93a5311-4689-486b-aea8-261263f4d447@lucifer.local>
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.
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.
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 19:30 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Sasha Levin, Dave Hansen, Dave Hansen, Dave Hansen, linux-kernel,
Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Luis Chamberlain, SeongJae Park, Dan Williams, Steven Rostedt,
NeilBrown, Theodore Ts'o, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <b7469e4e-d711-467f-839f-4a9688d25a23@lucifer.local>
On Thu, Jan 08, 2026 at 07:28:13PM +0000, Lorenzo Stoakes wrote:
> On Thu, Jan 08, 2026 at 07:27:17PM +0100, Miguel Ojeda wrote:
> > On Thu, Jan 8, 2026 at 5:42 PM Sasha Levin <sashal@kernel.org> wrote:
> > >
> > > We already have something like this in Documentation/process/howto.rst:
Sorry I missed here that that you referenced another document.
I think it's useful to have the emphasis I mentioned in a single place so
people can be referred there as to our expectaitons re: tool-generated
code. People are far more likely to miss things if located elsewhere.
So if we have emphasis on this there, it should make it even more sensible
to have emphasis here too.
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 19:28 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Sasha Levin, Dave Hansen, Dave Hansen, Dave Hansen, linux-kernel,
Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Luis Chamberlain, SeongJae Park, Dan Williams, Steven Rostedt,
NeilBrown, Theodore Ts'o, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <CANiq72mw1bis7aE9b=Htx9=Sd9jZH1rJmew1xqhPiCWu=EyzPw@mail.gmail.com>
On Thu, Jan 08, 2026 at 07:27:17PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 8, 2026 at 5:42 PM Sasha Levin <sashal@kernel.org> wrote:
> >
> > We already have something like this in Documentation/process/howto.rst:
> >
> > "Before making any actual modifications to the Linux kernel code, it is
> > imperative to understand how the code in question works."
>
> The patch already mentions something similar as well:
>
> Ensure that you understand your entire submission and are prepared
> to respond to review comments.
>
> And then talks about the maintainers discretion and rejecting etc. at
> the bullet list at the bottom, so it seems fairly clear to me, i.e.
> that patches may get "rejected outright" if one cannot explain the
> submitted series.
I understand that of course. I feel I said it already but perhaps I wasn't
clear. The issue is that this is put very softly and in such a way as to lose
emphasis:
'You _can_ be more transparent by adding information like this:...'
'As with all contributions, individual maintainers have discretion to
choose how they handle the contribution. For example, they _might_:'
'[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.'
All of this is a little weak and reads like 'please if you could take the
trouble we'd love if you'd maybe abide by this'.
The point is to say very clearly - we won't accept slop.
For all the various arguments I've seen on here, none have amounted to us being
happy to, so I hope that it's not too egregious to ask for that kind of
emphasis.
>
> Cheers,
> Miguel
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 19:23 UTC (permalink / raw)
To: Dave Hansen
Cc: James Bottomley, Dave Hansen, Dave Hansen, linux-kernel,
Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Luis Chamberlain, SeongJae Park, Dan Williams, Steven Rostedt,
NeilBrown, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <6e9cab54-7b66-45e9-af96-e52b3eba1034@intel.com>
On Thu, Jan 08, 2026 at 11:10:40AM -0800, Dave Hansen wrote:
> On 1/8/26 08:35, Lorenzo Stoakes wrote:
> <snip>
> >> +As with the output of any tooling,
> >>
> >> The result can be incorrect or inappropriate so
> >
> > LGTM! :)
> ...
>
> I tweaked James's version a wee bit, but I think I left the message in
> place. How does this hunk look?
>
> @@ -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.
?
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2026-01-08 19:16 UTC (permalink / raw)
To: Sasha Levin, Lorenzo Stoakes
Cc: Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, NeilBrown, Theodore Ts'o,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <aV_eiRqUsK2KWkww@laps>
On 1/8/26 08:42, Sasha Levin wrote:
> I suppose that we can restate the same here, but whats the purpose?
> to put it in front of whatever media outlets might be looking?
Yeah, that's my only objection to adding the new hunk that James and
Lorenzo were suggesting. It's arguably covered earlier in _this_ document:
> +Guidelines
> +==========
....
> +tool-generated contributions. Ensure that you understand your entire
> +submission and are prepared to respond to review comments.
But, if folks feel it's that important a point, I guess mentioning it
twice-ish is OK.
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2026-01-08 19:10 UTC (permalink / raw)
To: Lorenzo Stoakes, James Bottomley
Cc: Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, NeilBrown, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <a70d3156-ad96-4ad7-90ff-624fab62fe7d@lucifer.local>
On 1/8/26 08:35, Lorenzo Stoakes wrote:
<snip>
>> +As with the output of any tooling,
>>
>> The result can be incorrect or inappropriate so
>
> LGTM! :)
...
I tweaked James's version a wee bit, but I think I left the message in
place. How does this hunk look?
@@ -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.
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 18:30 UTC (permalink / raw)
To: Steven Rostedt
Cc: Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, NeilBrown, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260108131926.59b456fc@gandalf.local.home>
On Thu, Jan 08, 2026 at 01:19:26PM -0500, Steven Rostedt wrote:
> On Thu, 8 Jan 2026 11:29:47 +0000
> Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> > > But one thing I learned about my decade on the TAB, is don't worry about
> > > things you are afraid might happen, just make sure you address what is
> > > currently happening. Especially when it's easy to update the rules.
> >
> > I mean why are we even writing the document at all in that case :) why did this
> > discussion come up at the maintainer's summit, etc.
>
> What happened that started this discussion was me reading about an AI patch
> that was submitted and accepted without the maintainer knowing that the
> patch was 100% created by AI. That maintainer just happened to be me! I
> made a stink about not disclosing the fact that the patch was generated by
> AI. I wanted full transparency.
>
> A long discussion started there where we noticed that we have no written
> policy on transparency of tooling used to create patches and wanted to fix
> that. That was the reason this all started, but it expanded to "Oh we need
> to document our policy on AI too". That was an after thought.
>
> See why I'm still pushing to only document what our current policy is.
Hm, not sure I can square that with 'these rules already existed'. Were they
unwritten rules...?
I mean from my + outside world's perspective it kicked off from Sasha sending
the patch adding config files for LLM tooling, then the MS thread(s), then this
thread.
Though obviously you mentioned that occasion there.
>
> >
> > I think it's sensible to establish a clear policy on how we deal with this
> > _ahead of time_.
>
> Why? We don't know what is going to happen. We are only assuming things are
> going to be a problem, where it may never be.
I mean google 'AI slop'. If you think the kernel is mysteriously immune to it
I'd be curious as to the justification.
As a maintainer I find it mildly irritating that you'd be so resistant to very
small changes to the document to put a little more emphasis on this and instead
ask me to wait until I'm overwhelmed.
It's not really a huge ask.
>
> >
> > And as I said to Linus (and previously in discussions on this) I fear the
> > press reporting 'linux kernel welcomes AI submissions, sees it like any
> > other tool'.
>
> But this document doesn't even say that. It's only expressing in writing
> what our policy is on transparency of using tooling where AI is just one
> more tool. AI submissions have already been done. It's only accepted after
> the normal process is followed.
Honestly you really think that people are looking at this as a general 'tools'
thing and not about AI? Really? I mean have you _read_ kernel reporting lately,
especially the more tabloid clickbaity stuff?
>
> -- Steve
Honestly this is all moot as Linus has made his position clear. But I wanted to
be heard.
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Miguel Ojeda @ 2026-01-08 18:27 UTC (permalink / raw)
To: Sasha Levin
Cc: Lorenzo Stoakes, Dave Hansen, Dave Hansen, Dave Hansen,
linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, NeilBrown, Theodore Ts'o, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <aV_eiRqUsK2KWkww@laps>
On Thu, Jan 8, 2026 at 5:42 PM Sasha Levin <sashal@kernel.org> wrote:
>
> We already have something like this in Documentation/process/howto.rst:
>
> "Before making any actual modifications to the Linux kernel code, it is
> imperative to understand how the code in question works."
The patch already mentions something similar as well:
Ensure that you understand your entire submission and are prepared
to respond to review comments.
And then talks about the maintainers discretion and rejecting etc. at
the bullet list at the bottom, so it seems fairly clear to me, i.e.
that patches may get "rejected outright" if one cannot explain the
submitted series.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-08 18:19 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, NeilBrown, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <f72c3894-f83c-4bb9-abfb-afc2aa22c705@lucifer.local>
On Thu, 8 Jan 2026 11:29:47 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> > But one thing I learned about my decade on the TAB, is don't worry about
> > things you are afraid might happen, just make sure you address what is
> > currently happening. Especially when it's easy to update the rules.
>
> I mean why are we even writing the document at all in that case :) why did this
> discussion come up at the maintainer's summit, etc.
What happened that started this discussion was me reading about an AI patch
that was submitted and accepted without the maintainer knowing that the
patch was 100% created by AI. That maintainer just happened to be me! I
made a stink about not disclosing the fact that the patch was generated by
AI. I wanted full transparency.
A long discussion started there where we noticed that we have no written
policy on transparency of tooling used to create patches and wanted to fix
that. That was the reason this all started, but it expanded to "Oh we need
to document our policy on AI too". That was an after thought.
See why I'm still pushing to only document what our current policy is.
>
> I think it's sensible to establish a clear policy on how we deal with this
> _ahead of time_.
Why? We don't know what is going to happen. We are only assuming things are
going to be a problem, where it may never be.
>
> And as I said to Linus (and previously in discussions on this) I fear the
> press reporting 'linux kernel welcomes AI submissions, sees it like any
> other tool'.
But this document doesn't even say that. It's only expressing in writing
what our policy is on transparency of using tooling where AI is just one
more tool. AI submissions have already been done. It's only accepted after
the normal process is followed.
-- Steve
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 17:40 UTC (permalink / raw)
To: Sasha Levin
Cc: Dave Hansen, Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan,
Kees Cook, Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain,
SeongJae Park, Dan Williams, Steven Rostedt, NeilBrown,
Theodore Ts'o, Jonathan Corbet, Vlastimil Babka, workflows,
ksummit
In-Reply-To: <aV_eiRqUsK2KWkww@laps>
On Thu, Jan 08, 2026 at 11:42:49AM -0500, Sasha Levin wrote:
> On Thu, Jan 08, 2026 at 11:56:19AM +0000, Lorenzo Stoakes wrote:
> > diff --git a/Documentation/process/generated-content.rst b/Documentation/process/generated-content.rst
> > index 917d6e93c66d..1423ed9d971d 100644
> > --- a/Documentation/process/generated-content.rst
> > +++ b/Documentation/process/generated-content.rst
> > @@ -95,3 +95,11 @@ 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.
> > +
> > +If tools permit you to generate series entirely automatically, expect
> > +additional scrutiny.
> > +
> > +As with the output of any tooling, maintainers will not tolerate 'slop' -
>
> Could you define what "slop" in the context of a kernel patch means? Clearly
> it's not just innocent error, but it's not clear to me what line needs to be
> crossed for a mistake to turn into "slop".
I accepted James's suggested alternative in this thread.
>
> > +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.
>
> We already have something like this in Documentation/process/howto.rst:
>
> "Before making any actual modifications to the Linux kernel code, it is
> imperative to understand how the code in question works."
>
> I suppose that we can restate the same here, but whats the purpose? to put it
> in front of whatever media outlets might be looking?
I feel I've already addressed this in the thread.
>
> --
> Thanks,
> Sasha
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH v6 4/5] slab: Introduce kmalloc_flex() and family
From: Kees Cook @ 2026-01-08 17:40 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Jonathan Corbet, Andrew Morton, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Gustavo A. R. Silva, workflows,
linux-doc, linux-mm, linux-hardening, Linus Torvalds,
Randy Dunlap, Miguel Ojeda, Przemek Kitszel, Matthew Wilcox,
John Hubbard, Joe Perches, Christoph Lameter, Marco Elver,
Vegard Nossum, Pekka Enberg, Joonsoo Kim, Bill Wendling,
Justin Stitt, Jann Horn, Greg Kroah-Hartman, Sasha Levin,
Nathan Chancellor, Peter Zijlstra, Nick Desaulniers,
Jakub Kicinski, Yafang Shao, Tony Ambardar, Alexander Lobakin,
Jan Hendrik Farr, Alexander Potapenko, linux-kernel, llvm
In-Reply-To: <f1f06db9-a12c-4999-9723-1fca5e8383a4@suse.cz>
On Thu, Jan 08, 2026 at 03:06:31PM +0100, Vlastimil Babka wrote:
> On 12/4/25 00:30, Kees Cook wrote:
> > As done for kmalloc_obj*(), introduce a type-aware allocator for flexible
> > arrays, which may also have "counted_by" annotations:
> >
> > ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
> >
> > becomes:
> >
> > ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> >
> > The internal use of __flex_counter() allows for automatically setting
> > the counter member of a struct's flexible array member when it has
> > been annotated with __counted_by(), avoiding any missed early size
> > initializations while __counted_by() annotations are added to the
> > kernel. Additionally, this also checks for "too large" allocations based
> > on the type size of the counter variable. For example:
> >
> > if (count > type_max(ptr->flex_counter))
> > fail...;
> > size = struct_size(ptr, flex_member, count);
> > ptr = kmalloc(size, gfp);
> > ptr->flex_counter = count;
> >
> > becomes (n.b. unchanged from earlier example):
> >
> > ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> > ptr->flex_count = count;
>
> ^ flex_counter ?
>
> But if it was "too large", ptr is NULL so this will oops?
I've changed this to:
...
based on the type size of the counter variable. For example:
if (count > type_max(ptr->flex_counter))
fail...;
size = struct_size(ptr, flex_member, count);
ptr = kmalloc(size, gfp);
if (!ptr)
fail...;
ptr->flex_counter = count;
becomes (n.b. unchanged from earlier example):
ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
if (!ptr)
fail...;
ptr->flex_counter = count;
May I add your Acked-by for this 4/5 patch?
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v6 4/5] slab: Introduce kmalloc_flex() and family
From: Kees Cook @ 2026-01-08 17:12 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Jonathan Corbet, Andrew Morton, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Gustavo A. R. Silva, workflows,
linux-doc, linux-mm, linux-hardening, Linus Torvalds,
Randy Dunlap, Miguel Ojeda, Przemek Kitszel, Matthew Wilcox,
John Hubbard, Joe Perches, Christoph Lameter, Marco Elver,
Vegard Nossum, Pekka Enberg, Joonsoo Kim, Bill Wendling,
Justin Stitt, Jann Horn, Greg Kroah-Hartman, Sasha Levin,
Nathan Chancellor, Peter Zijlstra, Nick Desaulniers,
Jakub Kicinski, Yafang Shao, Tony Ambardar, Alexander Lobakin,
Jan Hendrik Farr, Alexander Potapenko, linux-kernel, llvm
In-Reply-To: <f1f06db9-a12c-4999-9723-1fca5e8383a4@suse.cz>
On Thu, Jan 08, 2026 at 03:06:31PM +0100, Vlastimil Babka wrote:
> On 12/4/25 00:30, Kees Cook wrote:
> > As done for kmalloc_obj*(), introduce a type-aware allocator for flexible
> > arrays, which may also have "counted_by" annotations:
> >
> > ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
> >
> > becomes:
> >
> > ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> >
> > The internal use of __flex_counter() allows for automatically setting
> > the counter member of a struct's flexible array member when it has
> > been annotated with __counted_by(), avoiding any missed early size
> > initializations while __counted_by() annotations are added to the
> > kernel. Additionally, this also checks for "too large" allocations based
> > on the type size of the counter variable. For example:
> >
> > if (count > type_max(ptr->flex_counter))
> > fail...;
> > size = struct_size(ptr, flex_member, count);
> > ptr = kmalloc(size, gfp);
> > ptr->flex_counter = count;
> >
> > becomes (n.b. unchanged from earlier example):
> >
> > ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> > ptr->flex_count = count;
>
> ^ flex_counter ?
>
> But if it was "too large", ptr is NULL so this will oops?
Oops, yes, typo in the example. I will fix that. As for NULL, I dropped
the NULL checking on both sides of the example just to focus on the
differences.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Sasha Levin @ 2026-01-08 16:42 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Dave Hansen, Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan,
Kees Cook, Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain,
SeongJae Park, Dan Williams, Steven Rostedt, NeilBrown,
Theodore Ts'o, Jonathan Corbet, Vlastimil Babka, workflows,
ksummit
In-Reply-To: <611c4a95-cbf2-492c-a991-e54042cf226a@lucifer.local>
On Thu, Jan 08, 2026 at 11:56:19AM +0000, Lorenzo Stoakes wrote:
>diff --git a/Documentation/process/generated-content.rst b/Documentation/process/generated-content.rst
>index 917d6e93c66d..1423ed9d971d 100644
>--- a/Documentation/process/generated-content.rst
>+++ b/Documentation/process/generated-content.rst
>@@ -95,3 +95,11 @@ 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.
>+
>+If tools permit you to generate series entirely automatically, expect
>+additional scrutiny.
>+
>+As with the output of any tooling, maintainers will not tolerate 'slop' -
Could you define what "slop" in the context of a kernel patch means? Clearly
it's not just innocent error, but it's not clear to me what line needs to be
crossed for a mistake to turn into "slop".
>+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.
We already have something like this in Documentation/process/howto.rst:
"Before making any actual modifications to the Linux kernel code, it is
imperative to understand how the code in question works."
I suppose that we can restate the same here, but whats the purpose? to put it
in front of whatever media outlets might be looking?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 16:35 UTC (permalink / raw)
To: James Bottomley
Cc: Dave Hansen, Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan,
Kees Cook, Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain,
SeongJae Park, Dan Williams, Steven Rostedt, NeilBrown,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <e7a2e69991943777f30743868bdc04332a52037b.camel@HansenPartnership.com>
On Thu, Jan 08, 2026 at 10:58:08AM -0500, James Bottomley wrote:
> On Thu, 2026-01-08 at 13:56 +0000, Lorenzo Stoakes wrote:
> > On Thu, Jan 08, 2026 at 08:17:09AM -0500, James Bottomley wrote:
> > > On Thu, 2026-01-08 at 11:56 +0000, Lorenzo Stoakes wrote:
> [...]
> > > > +
> > > > +As with the output of any tooling,
> > >
> > >
> > > > maintainers will not tolerate 'slop' -
> > >
> > > Just delete this phrase (partly because it's very tied to a non-
> > > standard and very recent use of the word slop, but mostly because
> > > it doesn't add anything actionable to the reader).
> >
> > I mean I'm not expecting this to land given Linus's position :)
> >
> > But if removing this sentence allowed the below in sure.
> >
> > However personally I think it's very important to say 'slop' here.
> > It's more so to make it abundantly clear that the kernel takes the
> > position that we don't accept it.
>
> Perhaps I can help clarify. You're using the word "slop" to mean
> output of tools that is actually wrong ... which can happen to any
> tool, not just AI. And you want any statement to include that
> explicitly.
>
> I'm saying anything you can't explain won't be accepted, which, I
> think, necessarily includes any output the tool gets wrong. But I
> don't object to saying this in a more generic form, so how about this
> as the compromise
>
> ---
> +As with the output of any tooling,
>
> The result can be incorrect or inappropriate so
LGTM! :)
>
> +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.
> ---
>
> Regards,
>
> James
>
Cheers, Lorenzo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox