* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: SeongJae Park @ 2026-01-08 0:00 UTC (permalink / raw)
To: Dave Hansen
Cc: SeongJae Park, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, Dan Williams,
Steven Rostedt, NeilBrown, Lorenzo Stoakes, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260106205105.4037716-1-dave.hansen@linux.intel.com>
Nit. Apparently this is v4, not v3? I show v3 from
https://lore.kernel.org/20251114183528.1239900-1-dave.hansen@linux.intel.com
On Tue, 6 Jan 2026 12:51:05 -0800 Dave Hansen <dave.hansen@linux.intel.com> wrote:
[...]
Thanks,
SJ
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Linus Torvalds @ 2026-01-08 0:06 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, Steven Rostedt, NeilBrown, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <1c74353c-40de-4d0b-a517-92a94f8b4af8@lucifer.local>
On Wed, 7 Jan 2026 at 13:20, Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> Thinking LLMs are 'just another tool' is to say effectively that the kernel
> is immune from this. Which seems to me a silly position.
No. Your position is the silly one.
There is *zero* point in talking about AI slop. That's just plain stupid.
Why? Because the AI slop people aren't going to document their patches
as such. That's such an obvious truism that I don't understand why
anybody even brings up AI slop.
So stop this idiocy.
The documentation is for good actors, and pretending anything else is
pointless posturing.
As I said in private elsewhere, I do *not* want any kernel development
documentation to be some AI statement. We have enough people on both
sides of the "sky is falling" and "it's going to revolutionize
software engineering", I don't want some kernel development docs to
take either stance.
It's why I strongly want this to be that "just a tool" statement.
And the AI slop issue is *NOT* going to be solved with documentation,
and anybody who thinks it is either just naive, or wants to "make a
statement".
Neither of which is a good reason for documentation.
Linus
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2026-01-08 0:20 UTC (permalink / raw)
To: Lorenzo Stoakes, Dave Hansen
Cc: 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: <1c74353c-40de-4d0b-a517-92a94f8b4af8@lucifer.local>
On 1/7/26 13:15, Lorenzo Stoakes wrote:
> Thinking LLMs are 'just another tool' is to say effectively that the kernel
> is immune from this. Which seems to me a silly position.
I had a good chat with Lorenzo on IRC. I had it in my head that he
wanted a really different document than the one I posted. After talking,
it sounds like he had some much more modest changes in mind. I caught
him at the end of his day, but I think he's planning to send out a small
diff on top of what I posted so I can get a better idea of what he wants
to see tweaked.
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 10:03 UTC (permalink / raw)
To: Linus Torvalds
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,
Chris Mason
In-Reply-To: <CAHk-=wg0sdh_OF8zgFD-f6o9yFRK=tDOXhB1JAxfs11W9bX--Q@mail.gmail.com>
+cc Chris as I mention him :)
On Wed, Jan 07, 2026 at 04:06:35PM -0800, Linus Torvalds wrote:
> On Wed, 7 Jan 2026 at 13:20, Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> >
> > Thinking LLMs are 'just another tool' is to say effectively that the kernel
> > is immune from this. Which seems to me a silly position.
>
> No. Your position is the silly one.
>
> There is *zero* point in talking about AI slop. That's just plain stupid.
>
> Why? Because the AI slop people aren't going to document their patches
> as such. That's such an obvious truism that I don't understand why
> anybody even brings up AI slop.
The point is:
a. For the tech press to not gleefully report that the kernel just accepts AI
patches now since hey it's just another tool.
b. To be able to refer back to the document when rejecting series.
As to point a., as I said before in other threads, I remain concerned that
the second the tech press say 'the kernel accepts AI patches now' we'll see
an influx.
It's sad we have to think about that, but it's a fact of life.
>
> So stop this idiocy.
>
> The documentation is for good actors, and pretending anything else is
> pointless posturing.
I mean with respect, if the document is saying in effect 'hey everything's
the same relax', what's the point of the document again?
>
> As I said in private elsewhere, I do *not* want any kernel development
> documentation to be some AI statement. We have enough people on both
> sides of the "sky is falling" and "it's going to revolutionize
> software engineering", I don't want some kernel development docs to
> take either stance.
To be clear I am actually quite optimistic about AI tooling in some areas,
most notably review (Chris Mason is doing some great work on this for
instance! :)
My suggestions are _not_ taking either position.
They are just there to address points a and b above, while otherwise
retaining the same exact position as the document currently does.
(I actually feel the rest of the document is good, as I said in v1 review,
Dave + of course the other reviewers did a good job.)
>
> It's why I strongly want this to be that "just a tool" statement.
>
> And the AI slop issue is *NOT* going to be solved with documentation,
> and anybody who thinks it is either just naive, or wants to "make a
> statement".
I mean, not sure I said we'd be solving AI slop here :) if we could solve
it with a document that'd be great, but I'm not that naive/hopeful
obviously.
Dave asked me to send an incremental patch to the documentation to be
entirely clear as to what change I'm suggesting, I am happy to do that
FWIW.
Perhaps that'll make my suggestion a little clearer.
>
> Neither of which is a good reason for documentation.
>
> Linus
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 10:14 UTC (permalink / raw)
To: Dave Hansen
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: <6c71554c-4fa1-4b99-9d46-2f1a2ecc1b7f@intel.com>
On Wed, Jan 07, 2026 at 04:20:04PM -0800, Dave Hansen wrote:
> On 1/7/26 13:15, Lorenzo Stoakes wrote:
> > Thinking LLMs are 'just another tool' is to say effectively that the kernel
> > is immune from this. Which seems to me a silly position.
>
> I had a good chat with Lorenzo on IRC. I had it in my head that he
> wanted a really different document than the one I posted. After talking,
> it sounds like he had some much more modest changes in mind. I caught
> him at the end of his day, but I think he's planning to send out a small
> diff on top of what I posted so I can get a better idea of what he wants
> to see tweaked.
Ack thanks Dave, FWIW if that'd be useful I can do that just to really clarify
what I mean here rather than hand wave.
Will take a look at doing that a little later.
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 10:29 UTC (permalink / raw)
To: dan.j.williams
Cc: Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Steven Rostedt, NeilBrown, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <695ef146d651b_4b7a1002a@dwillia2-mobl4.notmuch>
On Wed, Jan 07, 2026 at 03:50:30PM -0800, dan.j.williams@intel.com wrote:
> Lorenzo Stoakes wrote:
> [..]
> > And it's not like I'm asking for much, I'm not asking you to rewrite the
> > document, or take an entirely different approach, I'm just saying that we
> > should highlight that :
> >
> > 1. LLMs _allow you to send patches end-to-end without expertise_.
> >
> > 2. As a result, even though the community (rightly) strongly disapproves of
> > blanket dismissals of series, if we suspect AI slop [I think it's useful
> > to actually use that term], maintains can reject it out of hand.
> >
> > Point 2 is absolutely a new thing in my view.
>
> I worry what this sentiment does to the health of the project. Is
> "hunting for slop" really what we want to be doing? When the accusation
> is false, what then?
Yeah that's a very good point, and we don't want a witch hunt.
In fact in practice already I've had discussions with other maintainers about
series that seemed to have LLM elements in them (entirely in good faith I might
add).
Really I'm talking about series that are _very clearly_ slop.
And it's about the asymmetry between maintainer resource and the capacity for
people to send mountains of code.
The ability to send things completely end-to-end is the big difference here
vs. other tooling.
>
> If the goal of the wording change is to give cover and license for that
> kind of activity, I have a hard time seeing that as good for the
> project.
I agree entirely, and I absolutely do not want that.
>
> It has always been the case that problematic submitters put stress on
> maintainer bandwidth. Having a name for one class of potential
> maintainer stress in a process document does not advance the status quo.
>
> A maintainer is trusted to maintain the code and have always been able
> to give feedback of "I don't like it, leaves a bad taste", "I don't
> trust it does what it claims", or "I don't trust you, $submitter, to be
> able to maintain the implications of this proposal long term". That
> feedback is not strictly technical, but it is more actionable than "this
> is AI slop".
I really don't think it is the case that maintainers can simplly dismiss an
entire series like that.
The reason why is that, unlike e.g. a coccinelle script or something, this
won't be doing just cleanups, or fixing scope, or whatever.
LLMs can uniquely allow you to send a series that is entirely novel,
introducing new functionality or making significant changes.
For good reason, the community frowns upon just-rejecting that kind of
series without providing technical feedback.
There's a spectrum of opinions on these tools - on the extreme positive
side you have people who'd say we _should_ accept such series, or at least
review them in detail each time. On the extreme negative people would say
you should reject anything like this altogether even if you don't state
that an LLM helped you.
I think you'd probably agree both extremes are silly, but even many
moderate positions would leave the 'should we review these in detail'
rather blurry.
And thus it isn't therefore entirely clear that a maintainer dismissing
these kinds of series out of hand wouldn't be violating the norm of 'don't
reject series without technical reasoning'.
It would therefore be useful for the document to make it clear that they in
fact can.
Otherwise I fear we don't have an answer for the asymmetry issue. And as I
said to Linus, I think it'd be useful to be able to reference the document
in doing so.
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 10:32 UTC (permalink / raw)
To: 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: <6ec883cfe97bf9eb50f71b00c24723f5ed4c273e.camel@HansenPartnership.com>
On Wed, Jan 07, 2026 at 05:39:48PM -0500, James Bottomley wrote:
> On Wed, 2026-01-07 at 21:15 +0000, Lorenzo Stoakes wrote:
> > On Wed, Jan 07, 2026 at 11:18:52AM -0800, Dave Hansen wrote:
> > > On 1/7/26 10:12, Lorenzo Stoakes wrote:
> > > ...
> > > > I know Linus had the cute interpretation of it 'just being
> > > > another tool' but never before have people been able to do this.
> > >
> > > I respect your position here. But I'm not sure how to reconcile:
> > >
> > > LLMs are just another tool
> > > and
> > > LLMs are not just another tool
> > >
> > > :)
> >
> > Well I'm not asking you to reconcile that, I'm providing my point of
> > view which disagrees with the first position and makes a case for the
> > second. Isn't review about feedback both positive and negative?
> >
> > Obviously if this was intended to simply inform the community of the
> > committee's decision then apologies for misinterpreting it.
> >
> > I would simply argue that LLMs are not another tool on the basis of
> > the drastic negative impact its had in very many areas, for which you
> > need only take a cursory glance at the world to observe.
> >
> > Thinking LLMs are 'just another tool' is to say effectively that the
> > kernel is immune from this. Which seems to me a silly position.
>
> All tools are double edged and the better a tool is the more
> problematic its harmful uses become but people often use them anyway
> because of the beneficial uses. You don't for instance classify
> chainsaws as not another tool because they can be used to deforest the
> Amazon. All the document is saying is that we start from the place of
> treating AI like any other tool and, like any other tool, if it proves
> to cause way more problems than it solves, then we can then move on to
> other things. There are other tools we've tried and abandoned (like
> compiling the kernel with c++), so this really isn't any different.
I mean using the same analogy I'd say the existing norms are designed for
spoons, you'd probably not want to apply those same to a chainsaw :)
>
> Regards,
>
> James
>
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 10:40 UTC (permalink / raw)
To: Dirk Hohndel
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: <42192F04-2C46-4734-8CF6-DEA8739989C3@hohndel.org>
On Wed, Jan 07, 2026 at 01:37:04PM -0800, Dirk Hohndel wrote:
>
>
> > On Jan 7, 2026, at 13:15, Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> >
> > On Wed, Jan 07, 2026 at 11:18:52AM -0800, Dave Hansen wrote:
> >> ...
> >>> I know Linus had the cute interpretation of it 'just being another tool'
> >>> but never before have people been able to do this.
> >>
> >> I respect your position here. But I'm not sure how to reconcile:
> >>
> >> LLMs are just another tool
> >> and
> >> LLMs are not just another tool
> >>
> >> :)
> >
> > Well I'm not asking you to reconcile that, I'm providing my point of view
> > which disagrees with the first position and makes a case for the
> > second. Isn't review about feedback both positive and negative?
> >
> > Obviously if this was intended to simply inform the community of the
> > committee's decision then apologies for misinterpreting it.
> >
> > I would simply argue that LLMs are not another tool on the basis of the
> > drastic negative impact its had in very many areas, for which you need only
> > take a cursory glance at the world to observe.
> >
> > Thinking LLMs are 'just another tool' is to say effectively that the kernel
> > is immune from this. Which seems to me a silly position.
>
> I think Linus' position is based on what the LLM does when it comes to writing
> code. Your position is based on the impact that LLMs have when it comes to
> 'regular' maintainers (since he ignores GitHub PRs and only takes merge requests
> sent directly to him, I don't think he ever sees just how much garbage gets sent
> to maintainers...)
Yes, absolutely.
>
> >> For now, I think the existing rules are holding. We have the luxury of
> >
> > We're noticing a lot more LLM slop than we used to. It is becoming more and
> > more of an issue.
>
> The kernel isn't alone in getting garbage PRs, but I think for the kernel the initial
> hurdle to creating a PR was bigger than for most other projects, so the sudden
> increase in slop is likely felt even more.
Absolutely. This is exactly the problem. And LLMs uniquely enable people to send
these end-to-end. This is why they are different from previous tools.
>
> > And it's not like I'm asking for much, I'm not asking you to rewrite the
> > document, or take an entirely different approach, I'm just saying that we
> > should highlight that :
> >
> > 1. LLMs _allow you to send patches end-to-end without expertise_.
> >
> > 2. As a result, even though the community (rightly) strongly disapproves of
> > blanket dismissals of series, if we suspect AI slop [I think it's useful
> > to actually use that term], maintains can reject it out of hand.
> >
> > Point 2 is absolutely a new thing in my view.
>
> And as much as I respect the desire to be open to new tools and to encourage
> new developers, I think this statement is very much on point and useful to
> include.
> (of course, my opinion isn't all that relevant, given how long it has been that
> I have sent kernel merge requests)
Thanks :)
Well I don't send any merge requests to Linus direct myself as a sub-maintainer
in mm ;) so if that were the criteria I'd fail on that also! :)
>
> /D
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 11:29 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: <20260107165816.63ff25ac@gandalf.local.home>
On Wed, Jan 07, 2026 at 04:58:16PM -0500, Steven Rostedt wrote:
> On Wed, 7 Jan 2026 21:15:17 +0000
> Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
>
> > I would simply argue that LLMs are not another tool on the basis of the
> > drastic negative impact its had in very many areas, for which you need only
> > take a cursory glance at the world to observe.
> >
> > Thinking LLMs are 'just another tool' is to say effectively that the kernel
> > is immune from this. Which seems to me a silly position.
>
> But has this started to become a real problem with the kernel today?
It's becoming a problem. And as I said to Linus I seriously worry about what
news coverage of the kernel's stance on these kinds of series will do.
>
> >
> > >
> > > Let's look at it another way: What we all *want* for the kernel is
> > > simplicity. Simple rules, simple documentation, simple code. The
> > > simplest way to deal with the LLM onslaught is to pray that our existing
> > > rules will suffice.
> >
> > I'm not sure we really have rules quite as clearly as you say, as
> > subsystems differ greatly in what they do.
> >
> > For one mm merges patches unless averse review is received. Which means a
> > sudden influx of LLM series is likely to lead to real problems. Not all
> > subsystems are alike like this.
>
> But has this happened yet?
You're doing the 'repeat for emphasis' thing here which I respect as a useful
literary tool :) but addressed above.
>
> >
> > One rule that seems consistent is that arbitrary dismissal of series is
> > seriously frowned upon.
>
> If it is AI slop coming in, you can say, "unless you can prove to me that
> you understand this series and there's nothing wrong with it, I'm rejecting
> it"
>
> If the series looks good then what's the issue. But if it's AI slop and
> it's obvious the person behind the code doesn't understand what they are
> submitting, that could even be rationale for sending that person to your
> /dev/null folder.
Right, sure, but I feel this sits outside of current norms, I made a case for it
in my reply to Dan [0].
[0]:https://lore.kernel.org/ksummit/12d910d5-0937-4aba-976c-9872289d21a4@lucifer.local/
>
> >
> > The document claims otherwise.
> >
> > >
> > > For now, I think the existing rules are holding. We have the luxury of
> >
> > We're noticing a lot more LLM slop than we used to. It is becoming more and
> > more of an issue.
>
> Are you noticing this in submissions?
Yes.
>
> >
> > Secondly, as I said in my MS thread and maybe even in a previous version of
> > this one (can't remember) - I fear that once it becomes public that we are
> > open to LLM patches, the floodgates will open.
>
> This document is not about addressing anything that we fear will happen. It
> is only to state our current view of how things work today.
>
> If the floodgates do open and we get inundated with AI slop, then we can
> most definitely update his document to have a bit more teeth.
>
> 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.
I think it's sensible to establish a clear policy on how we deal with this
_ahead of time_.
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'.
So the tail could wag the dog here.
And is it really problematic to simply underline that that doesn't mean we
are ok with the unique ability of LLM's to allow submissions end-to-end in
bulk?
Again I'll send an incremental change showing what I actually want to
change here. Maybe that'll clarify my intent.
>
>
> >
> > The kernel has a thorny reputation of people pushing back, which probably
> > plays some role in holding that off.
> >
> > And it's not like I'm asking for much, I'm not asking you to rewrite the
> > document, or take an entirely different approach, I'm just saying that we
> > should highlight that :
> >
> > 1. LLMs _allow you to send patches end-to-end without expertise_.
>
> Why does this need to be added to the document. I think we should only be
> addressing how we handle tool generated content.
Because of maintainer/review asymmetry and this being a uniquely new situation
which attacks that.
>
> >
> > 2. As a result, even though the community (rightly) strongly disapproves of
> > blanket dismissals of series, if we suspect AI slop [I think it's useful
> > to actually use that term], maintains can reject it out of hand.
> >
> > Point 2 is absolutely a new thing in my view.
>
> I don't believe that is necessary. I reject patches outright all the time.
> Especially checkpatch "fixes" on code that is already in the tree. I just
> say: "checkpatch is for patches, not accepted content. If it's not a real
> bug, don't use checkpatch."
I find it interesting that both examples given here are of trivially
rejectable things that nobody would object to.
Again see my reply to Dan for an argument as to why I feel this is
different.
>
> If the AI code is decent, why reject it? If it's slop, then yeah, you have
> a lot of reasons to reject it.
Because it takes time to review to determine that it's decent even if it
might be obvious it's entirely AI-generated in the first place?
>
> >
> > > treating LLMs like any other tool. That could change any day because
> > > some new tool comes along that's better at spamming patches at us. I
> > > think that's the point you're trying to make is that the dam might break
> > > any day and we should be prepared for it.
> > >
> > > Is that what it boils down to?
> >
> > I feel I've answered that above.
> >
> > >
> > > >> +As with all contributions, individual maintainers have discretion to
> > > >> +choose how they handle the contribution. For example, they might:
> > > >> +
> > > >> + - Treat it just like any other contribution.
> > > >> + - Reject it outright.
> > > >
> > > > This is really not correct, it's simply not acceptable in the community to
> > > > reject series outright without justification. Yes perhaps people do that,
> > > > but it's really not something that's accepted.
> > >
> > > I'm not quite sure how this gives maintainers a new ability to reject
> > > things without justification, or encourages them to reject
> > > tool-generated code in a new way.
> > >
> > > Let's say something generated by "checkpatch.pl --fix" that's trying to
> > > patch arch/x86/foo.c lands in my inbox. I personally think it's OK for
> > > me as a maintainer to say: "No thanks, checkpatch has burned me too many
> > > times in foo.c and I don't trust its output there." To me, that's
> > > rejecting it outright.
> > >
> > > Could you explain a bit how this might encourage bad maintainer behavior?
> >
> > I really don't understand your question or why you're formulating this to
> > be about bad maintainer behaviour?
> >
> > It's generally frowned upon in the kernel to outright reject series without
> > technical justification. I really don't see how you can say that is not the
> > case?
>
> If it's AI slop, then I'm sure you could easily find lots of technical
> justifications for rejecting it. Why do we need to explicitly state it
> here?.
Aha! Now you've honed on _exactly_ the problem. To find the technical
justification, you'd need to read through the series, and with the
asymmetry of maintainer/submitter resource this is an issue.
>
> >
> > LLM generated series won't be a trivial checkpatch.pl --fix change, you've
> > given a trivially identifiable case that you could absolutely justify.
>
> Is it trivial just because it's checkpatch? I gave another example above
> too. But if AI slop is coming in, I'm sure there's lots of reasons to
> reject it.
I mean come on Steve :) yes it is trivial.
Apologies, but I didn't pick up on the other example above?
>
> Are you saying that if there's good AI code coming in (I wouldn't call it
> slop then) that you want to outright reject it too?
No I'm saying that maintainers should be able to reserve the right in order
to not be overwhelmed.
>
> >
> > Again, I'm not really asking for much here. As a maintainer I am (very)
> > concerned about the asymmetry between what can be submitted vs. review
> > resource.
> >
> > And to me being able to reference this document and to say 'sorry this
> > appears to be AI slop so we can't accept it' would be really useful.
>
> Then why not come up with a list of reasons AI slop is bad and make a
> boiler plate and send that every time. Basically states that if you submit
> AI code, the burden is on the submitter to prove that they understand the
> code. Or would you like that explicitly stated in this document? Something
> like:
>
> - If you submit any type of tool generated code, then it is the
> responsibility of the submitter to prove to the maintainer that they
> understand the code that they are submitting. Otherwise the maintainer
> may simply reject the changes outright.
>
> ?
I mean of course I wholeheartedly agree with that. But we to some degree
already have that:
+ - 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.
I think it'd be most useful to actually show what change I'd like in a
diff, which I'll send in a little while.
It's more about emphasis than really radically changing anything in the
document.
>
> >
> > Referencing a document that tries very hard to say 'NOP' isn't quite so
> > useful.
>
> I don't think this document's goal was to be a pointer to show people why
> you are rejecting AI submissions. This is just a guideline to how tool
> generated code should be submitted.
It might not be the goal but it establishes kernel policy even if it seems
the desire is to say 'NOP', and would be useful for maintainers on the
ground.
If nobody references kernel policy in how they do things then what is the
use of kernel policy?
>
> It's about how things work today. It's not about how things will work going
> forward with AI submissions. That document is for another day.
I feel I've addressed this above, but we're already mentioning things that
pertain to possible AI slop. I don't think the position here can both be
'well we already address this with existing rules' and 'we have no need to
address this at all' at the same time.
And shouldn't we perhaps take a defensive position to make it abundantly
clear that we won't tolerate this _ahead of time_?
I obviously take Linus's point that many slop producers couldn't care less
about norms or documentation, but with the impact on the press reporting
and _general sense_ of what the kernel will tolerate + those who _will_
think they're abiding by the norms - that it actually will have a practical
impact.
>
> -- Steve
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Miguel Ojeda @ 2026-01-08 11:43 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: dan.j.williams, Dave Hansen, Dave Hansen, linux-kernel,
Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Luis Chamberlain, SeongJae Park, Steven Rostedt, NeilBrown,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <12d910d5-0937-4aba-976c-9872289d21a4@lucifer.local>
On Thu, Jan 8, 2026 at 11:29 AM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> I really don't think it is the case that maintainers can simplly dismiss an
> entire series like that.
I think Dan was referring to all kinds of series, i.e. maintainers
have leeway to reject proposals, whether they are big or small and
whether they are new features or cleanups.
After all, the project works by trusting maintainers to do the right
thing (i.e. the best they can with the information and time at their
disposal), but sometimes there may not be concrete technical reasons.
For instance, sometimes it is just a matter of bandwidth -- if
maintainers cannot maintain the code, and no one (that is trusted to
some degree) is willing to do so, then it would be a bad idea to take
the code anyway, even if the feature is great, whether LLM-generated
or not.
That is also why it is often said that it is a good idea to contact
maintainers/community before developing completely a new feature etc.
etc.
So if a subsystem suddenly starts to get an onslaught of series like
you warn about, then they cannot be expected to review and give
technical feedback to everything, and they will need to prioritize
somehow (e.g. fixes), or try to get more maintainers, or raise the
issue in ksummit, etc.
At least, that is my take, i.e. we need to allow maintainers to adjust
as things come. And, of course, as a community, we can always reassess
as conditions change.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 11:53 UTC (permalink / raw)
To: Miguel Ojeda
Cc: dan.j.williams, Dave Hansen, Dave Hansen, linux-kernel,
Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Luis Chamberlain, SeongJae Park, Steven Rostedt, NeilBrown,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <CANiq72nmAw0sZZHJfSoHOZ5rXgoi7O4kETASp2F62XyALqZ8gA@mail.gmail.com>
On Thu, Jan 08, 2026 at 12:43:50PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 8, 2026 at 11:29 AM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > I really don't think it is the case that maintainers can simplly dismiss an
> > entire series like that.
>
> I think Dan was referring to all kinds of series, i.e. maintainers
> have leeway to reject proposals, whether they are big or small and
> whether they are new features or cleanups.
Sure, but I would say it's reasonable that there's a norm in place that
rejecting series outright that aren't _trivially_ dismissable is bad if no
technical objection is given right?
The issue with LLMs is you can generate entirely novel series that aren't
so trivially dimissible but could very well have other signals to hand
e.g. brand new person, never done any kernel work before, sends a bunch of
series at once etc.
So maybe it's worth highlighting this?
>
> After all, the project works by trusting maintainers to do the right
> thing (i.e. the best they can with the information and time at their
> disposal), but sometimes there may not be concrete technical reasons.
>
> For instance, sometimes it is just a matter of bandwidth -- if
> maintainers cannot maintain the code, and no one (that is trusted to
> some degree) is willing to do so, then it would be a bad idea to take
> the code anyway, even if the feature is great, whether LLM-generated
> or not.
Haha well mm does just merge stuff even if there isn't review capacity :)
which I am arguing against presently as a very silly (and unworkable) thing
to do. But that's another debate...
>
> That is also why it is often said that it is a good idea to contact
> maintainers/community before developing completely a new feature etc.
> etc.
Yes, and we've seen in mm people come to the commnuity with a huge new
patchset that is rejected.
But it almost inevitably has _technical feedback_ as part of that reject
that took time, something that the asymmetry of slop wouldn't permit so
cleraly.
>
> So if a subsystem suddenly starts to get an onslaught of series like
> you warn about, then they cannot be expected to review and give
> technical feedback to everything, and they will need to prioritize
> somehow (e.g. fixes), or try to get more maintainers, or raise the
> issue in ksummit, etc.
Right, but we also need to be able to take the sensible approach of simply
not tolerating it.
I mean if the contention is we already in effect can do this, then surely
it's no harm to provide emphasis in the document no?
>
> At least, that is my take, i.e. we need to allow maintainers to adjust
> as things come. And, of course, as a community, we can always reassess
> as conditions change.
See my other point about the tail wags the dog effect when an official
kernel policy document appears to say 'open to business for LLMs'.
Linus has already been quoted in the press I believe with his 'LLMs are
just like any other tool'.
I wish we didn't have to think about that, but we do.
Anyway I'm submitting my suggested delta shortly. It's really not all that
much different from the rest, just putting some emphasis on the slop
aspect.
>
> Cheers,
> Miguel
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 11:56 UTC (permalink / raw)
To: Dave Hansen
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: <6c71554c-4fa1-4b99-9d46-2f1a2ecc1b7f@intel.com>
On Wed, Jan 07, 2026 at 04:20:04PM -0800, Dave Hansen wrote:
> On 1/7/26 13:15, Lorenzo Stoakes wrote:
> > Thinking LLMs are 'just another tool' is to say effectively that the kernel
> > is immune from this. Which seems to me a silly position.
>
> I had a good chat with Lorenzo on IRC. I had it in my head that he
> wanted a really different document than the one I posted. After talking,
> it sounds like he had some much more modest changes in mind. I caught
> him at the end of his day, but I think he's planning to send out a small
> diff on top of what I posted so I can get a better idea of what he wants
> to see tweaked.
I enclose the suggested incremental change below.
Cheers, Lorenzo
----8<----
From ccefc4da6b929914c754c2f898b0eb17d7fb3ebd Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Thu, 8 Jan 2026 11:55:10 +0000
Subject: [PATCH] suggestion
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
Documentation/process/generated-content.rst | 8 ++++++++
1 file changed, 8 insertions(+)
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' -
+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.
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: James Bottomley @ 2026-01-08 13:17 UTC (permalink / raw)
To: Lorenzo Stoakes, Dave Hansen
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: <611c4a95-cbf2-492c-a991-e54042cf226a@lucifer.local>
On Thu, 2026-01-08 at 11:56 +0000, Lorenzo Stoakes wrote:
> On Wed, Jan 07, 2026 at 04:20:04PM -0800, Dave Hansen wrote:
> > On 1/7/26 13:15, Lorenzo Stoakes wrote:
> > > Thinking LLMs are 'just another tool' is to say effectively that
> > > the kernel
> > > is immune from this. Which seems to me a silly position.
> >
> > I had a good chat with Lorenzo on IRC. I had it in my head that he
> > wanted a really different document than the one I posted. After
> > talking,
> > it sounds like he had some much more modest changes in mind. I
> > caught
> > him at the end of his day, but I think he's planning to send out a
> > small
> > diff on top of what I posted so I can get a better idea of what he
> > wants
> > to see tweaked.
>
> I enclose the suggested incremental change below.
>
> Cheers, Lorenzo
>
> ----8<----
> From ccefc4da6b929914c754c2f898b0eb17d7fb3ebd Mon Sep 17 00:00:00
> 2001
> From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Date: Thu, 8 Jan 2026 11:55:10 +0000
> Subject: [PATCH] suggestion
>
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
> Documentation/process/generated-content.rst | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> 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' -
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).
> +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.
And I thing the addition would apply to any tool used to generate a
patch set whether AI or not.
Regards,
James
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Andrew Lunn @ 2026-01-08 13:41 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, Steven Rostedt, NeilBrown, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <1c74353c-40de-4d0b-a517-92a94f8b4af8@lucifer.local>
> And it's not like I'm asking for much, I'm not asking you to rewrite the
> document, or take an entirely different approach, I'm just saying that we
> should highlight that :
>
> 1. LLMs _allow you to send patches end-to-end without expertise_.
As somebody who reviews a lot of networking patches, i already see
lots of human generated patches without expertise. So LLM might
increase the volume of such patches, but the concept itself is not
new, and does not require LLMs.
> 2. As a result, even though the community (rightly) strongly disapproves of
> blanket dismissals of series, if we suspect AI slop [I think it's useful
> to actually use that term], maintains can reject it out of hand.
And i do blanket dismiss all but one such patch from an author, and i
try to teach that author how to get that one patch into shape, in the
hope you can learn the processes and apply it to their other
patches. Sometimes the effort works, and you get a new developers
joining the community, sometimes it is a lost cause, and they go away
after having their patches repeatedly rejected.
So i don't think using LLMs makes a difference here. I've seen the
same issue with blindly fixing checkpatch warning, sparse warning,
other static analysis tool warnings. I just see LLMs are another such
tool.
> Point 2 is absolutely a new thing in my view.
And i would disagree with this statement, it is not new, it already
happens.
Andrew
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 13:53 UTC (permalink / raw)
To: Andrew Lunn
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: <c04c84a0-c38d-46e3-907d-e32191cfc9f8@lunn.ch>
On Thu, Jan 08, 2026 at 02:41:20PM +0100, Andrew Lunn wrote:
> > And it's not like I'm asking for much, I'm not asking you to rewrite the
> > document, or take an entirely different approach, I'm just saying that we
> > should highlight that :
> >
> > 1. LLMs _allow you to send patches end-to-end without expertise_.
>
> As somebody who reviews a lot of networking patches, i already see
> lots of human generated patches without expertise. So LLM might
I mean we all have :)
> increase the volume of such patches, but the concept itself is not
> new, and does not require LLMs.
The difference is the order of magnitude possible. There's a real barrier to
entry for clueless people, and there's a linearity in time taken to generate
submissions.
LLMs don't change the problem, they change the magnitude.
>
> > 2. As a result, even though the community (rightly) strongly disapproves of
> > blanket dismissals of series, if we suspect AI slop [I think it's useful
> > to actually use that term], maintains can reject it out of hand.
>
> And i do blanket dismiss all but one such patch from an author, and i
> try to teach that author how to get that one patch into shape, in the
> hope you can learn the processes and apply it to their other
> patches. Sometimes the effort works, and you get a new developers
> joining the community, sometimes it is a lost cause, and they go away
> after having their patches repeatedly rejected.
>
> So i don't think using LLMs makes a difference here. I've seen the
> same issue with blindly fixing checkpatch warning, sparse warning,
> other static analysis tool warnings. I just see LLMs are another such
> tool.
>
> > Point 2 is absolutely a new thing in my view.
>
> And i would disagree with this statement, it is not new, it already
> happens.
Well this is the thing - it varies by subsystem. In mm it's really not like
this.
At any rate, given you disagree - the document suggesting that maintainers
may dismiss out of hand shouldn't be in any way controversial :)
I have submitted an incremental diff to make concrete what I'm suggesting
at [0].
[0]:https://lore.kernel.org/ksummit/611c4a95-cbf2-492c-a991-e54042cf226a@lucifer.local/
>
> Andrew
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Michael S. Tsirkin @ 2026-01-08 14:01 UTC (permalink / raw)
To: James Bottomley
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, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <a60e0e566edbcbd70176045ae077176444ca25a9.camel@HansenPartnership.com>
On Thu, Jan 08, 2026 at 08:17:09AM -0500, James Bottomley wrote:
> > +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.
>
> And I thing the addition would apply to any tool used to generate a
> patch set whether AI or not.
Exactly. I saw my share of "fix checkpatch warning" slop. This is no
different.
--
MST
^ permalink raw reply
* Re: [PATCH v6 4/5] slab: Introduce kmalloc_flex() and family
From: Vlastimil Babka @ 2026-01-08 14:06 UTC (permalink / raw)
To: Kees Cook
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: <20251203233036.3212363-4-kees@kernel.org>
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?
> Note that manual initialization of the flexible array counter is still
> required (at some point) after allocation as not all compiler versions
> support the __counted_by annotation yet. But doing it internally makes
> sure they cannot be missed when __counted_by _is_ available, meaning
> that the bounds checker will not trip due to the lack of "early enough"
> initializations that used to work before enabling the stricter bounds
> checking. For example:
>
> ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> fill(ptr->flex, count);
> ptr->flex_count = count;
>
> This works correctly before adding a __counted_by annotation (since
> nothing is checking ptr->flex accesses against ptr->flex_count). After
> adding the annotation, the bounds sanitizer would trip during fill()
> because ptr->flex_count wasn't set yet. But with kmalloc_flex() setting
> ptr->flex_count internally at allocation time, the existing code works
> without needing to move the ptr->flex_count assignment before the call
> to fill(). (This has been a stumbling block for __counted_by adoption.)
>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Christoph Lameter <cl@gentwo.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> Cc: Harry Yoo <harry.yoo@oracle.com>
> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
> Cc: <workflows@vger.kernel.org>
> Cc: <linux-doc@vger.kernel.org>
> Cc: <linux-mm@kvack.org>
> Cc: <linux-hardening@vger.kernel.org>
> ---
> Documentation/process/deprecated.rst | 7 ++++
> include/linux/slab.h | 48 ++++++++++++++++++++++++++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> index 91c628fa2d59..fed56864d036 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -387,6 +387,7 @@ allocations. For example, these open coded assignments::
> ptr = kzalloc(sizeof(*ptr), gfp);
> ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> ptr = kcalloc(count, sizeof(*ptr), gfp);
> + ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
> ptr = kmalloc(sizeof(struct foo, gfp);
>
> become, respectively::
> @@ -395,4 +396,10 @@ become, respectively::
> ptr = kzalloc_obj(*ptr, gfp);
> ptr = kmalloc_objs(*ptr, count, gfp);
> ptr = kzalloc_objs(*ptr, count, gfp);
> + ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> __auto_type ptr = kmalloc_obj(struct foo, gfp);
> +
> +If `ptr->flex_member` is annotated with __counted_by(), the allocation
> +will automatically fail if `count` is larger than the maximum
> +representable value that can be stored in the counter member associated
> +with `flex_member`.
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 726457daedbd..2656ea610b68 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -982,6 +982,33 @@ void *kmalloc_nolock_noprof(size_t size, gfp_t gfp_flags, int node);
> (TYPE *)KMALLOC(__obj_size, GFP); \
> })
>
> +/**
> + * __alloc_flex - Allocate an object that has a trailing flexible array
> + * @KMALLOC: kmalloc wrapper function to use for allocation.
> + * @GFP: GFP flags for the allocation.
> + * @TYPE: type of structure to allocate space for.
> + * @FAM: The name of the flexible array member of @TYPE structure.
> + * @COUNT: how many @FAM elements to allocate space for.
> + *
> + * Returns: Newly allocated pointer to @TYPE with @COUNT-many trailing
> + * @FAM elements, or NULL on failure or if @COUNT cannot be represented
> + * by the member of @TYPE that counts the @FAM elements (annotated via
> + * __counted_by()).
> + */
> +#define __alloc_flex(KMALLOC, GFP, TYPE, FAM, COUNT) \
> +({ \
> + const size_t __count = (COUNT); \
> + const size_t __obj_size = struct_size_t(TYPE, FAM, __count); \
> + TYPE *__obj_ptr; \
> + if (WARN_ON_ONCE(overflows_flex_counter_type(TYPE, FAM, __count))) \
> + __obj_ptr = NULL; \
> + else \
> + __obj_ptr = KMALLOC(__obj_size, GFP); \
> + if (__obj_ptr) \
> + __set_flex_counter(__obj_ptr->FAM, __count); \
> + __obj_ptr; \
> +})
> +
> /**
> * kmalloc_obj - Allocate a single instance of the given type
> * @VAR_OR_TYPE: Variable or type to allocate.
> @@ -1005,23 +1032,44 @@ void *kmalloc_nolock_noprof(size_t size, gfp_t gfp_flags, int node);
> #define kmalloc_objs(VAR_OR_TYPE, COUNT, GFP) \
> __alloc_objs(kmalloc, GFP, typeof(VAR_OR_TYPE), COUNT)
>
> +/**
> + * kmalloc_flex - Allocate a single instance of the given flexible structure
> + * @VAR_OR_TYPE: Variable or type to allocate (with its flex array).
> + * @FAM: The name of the flexible array member of the structure.
> + * @COUNT: How many flexible array member elements are desired.
> + * @GFP: GFP flags for the allocation.
> + *
> + * Returns: newly allocated pointer to @VAR_OR_TYPE on success, NULL on
> + * failure. If @FAM has been annotated with __counted_by(), the allocation
> + * will immediately fail if @COUNT is larger than what the type of the
> + * struct's counter variable can represent.
> + */
> +#define kmalloc_flex(VAR_OR_TYPE, FAM, COUNT, GFP) \
> + __alloc_flex(kmalloc, GFP, typeof(VAR_OR_TYPE), FAM, COUNT)
> +
> /* All kzalloc aliases for kmalloc_(obj|objs|flex). */
> #define kzalloc_obj(P, GFP) \
> __alloc_objs(kzalloc, GFP, typeof(P), 1)
> #define kzalloc_objs(P, COUNT, GFP) \
> __alloc_objs(kzalloc, GFP, typeof(P), COUNT)
> +#define kzalloc_flex(P, FAM, COUNT, GFP) \
> + __alloc_flex(kzalloc, GFP, typeof(P), FAM, COUNT)
>
> /* All kvmalloc aliases for kmalloc_(obj|objs|flex). */
> #define kvmalloc_obj(P, GFP) \
> __alloc_objs(kvmalloc, GFP, typeof(P), 1)
> #define kvmalloc_objs(P, COUNT, GFP) \
> __alloc_objs(kvmalloc, GFP, typeof(P), COUNT)
> +#define kvmalloc_flex(P, FAM, COUNT, GFP) \
> + __alloc_flex(kvmalloc, GFP, typeof(P), FAM, COUNT)
>
> /* All kvzalloc aliases for kmalloc_(obj|objs|flex). */
> #define kvzalloc_obj(P, GFP) \
> __alloc_objs(kvzalloc, GFP, typeof(P), 1)
> #define kvzalloc_objs(P, COUNT, GFP) \
> __alloc_objs(kvzalloc, GFP, typeof(P), COUNT)
> +#define kvzalloc_flex(P, FAM, COUNT, GFP) \
> + __alloc_flex(kvzalloc, GFP, typeof(P), FAM, COUNT)
>
> #define kmem_buckets_alloc(_b, _size, _flags) \
> alloc_hooks(__kmalloc_node_noprof(PASS_BUCKET_PARAMS(_size, _b), _flags, NUMA_NO_NODE))
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 13:56 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: <a60e0e566edbcbd70176045ae077176444ca25a9.camel@HansenPartnership.com>
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:
> > On Wed, Jan 07, 2026 at 04:20:04PM -0800, Dave Hansen wrote:
> > > On 1/7/26 13:15, Lorenzo Stoakes wrote:
> > > > Thinking LLMs are 'just another tool' is to say effectively that
> > > > the kernel
> > > > is immune from this. Which seems to me a silly position.
> > >
> > > I had a good chat with Lorenzo on IRC. I had it in my head that he
> > > wanted a really different document than the one I posted. After
> > > talking,
> > > it sounds like he had some much more modest changes in mind. I
> > > caught
> > > him at the end of his day, but I think he's planning to send out a
> > > small
> > > diff on top of what I posted so I can get a better idea of what he
> > > wants
> > > to see tweaked.
> >
> > I enclose the suggested incremental change below.
> >
> > Cheers, Lorenzo
> >
> > ----8<----
> > From ccefc4da6b929914c754c2f898b0eb17d7fb3ebd Mon Sep 17 00:00:00
> > 2001
> > From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > Date: Thu, 8 Jan 2026 11:55:10 +0000
> > Subject: [PATCH] suggestion
> >
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > ---
> > Documentation/process/generated-content.rst | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > 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' -
>
> 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.
Nothing else here really does make that clear in my opinion it's all far
too gently worded.
This is with an eye to press reporting also (they've already reported,
again, on the Linus's position that AI tools are just tools which I think
only helps propagate the idea that the kernel is open-for-business for AI
in general slop or otherwise).
>
> > +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.
>
> And I thing the addition would apply to any tool used to generate a
> patch set whether AI or not.
Right, yes agreed.
>
> Regards,
>
> James
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 14:24 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: James Bottomley, 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: <20260108085215-mutt-send-email-mst@kernel.org>
On Thu, Jan 08, 2026 at 09:01:09AM -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 08, 2026 at 08:17:09AM -0500, James Bottomley wrote:
> > > +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.
> >
> > And I thing the addition would apply to any tool used to generate a
> > patch set whether AI or not.
>
> Exactly. I saw my share of "fix checkpatch warning" slop. This is no
> different.
I'm a maintainer too and have seen this kinds of thing as well as many
variations on a theme of 'bad series'.
An analgous thing might be to ask anybody working in education how these tools
differ from all others students have used previously.
Checkpatch fixes and the like are relatively easy to identify and can only ever
be trivial changes which can be reasonably dismissed.
Whereas LLMs can generate entirely novel series that can't so easily be
dismissed, though the sudden appearance of a new person with completely new code
can be identified.
At any rate, even if you feel this is exactly the same, you surely therefore
cannot object to the suggested changes in [0] which would amount in your view
then to the same kind of dismissal you might give to a checkpatch --fix series?
The suggested change gives latitude to the maintainer to dismiss out of hand
should the pattern be obvious, or to use the nuclear weapon against slop of
asking somebody to explain the series (an LLM-generated explanation should be
fairly easy to spot in this case also...)
My motive here is the asymmetry between maintainer resource/patch influx which
is already at critical levels in at least some areas of mm. An uptick would be a
big problem right now.
Thanks, Lorenzo
[0]:https://lore.kernel.org/ksummit/611c4a95-cbf2-492c-a991-e54042cf226a@lucifer.local/
>
> --
> MST
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Michael S. Tsirkin @ 2026-01-08 14:28 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: James Bottomley, 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: <b8dc3dae-2d48-427a-be91-bcca53424d53@lucifer.local>
On Thu, Jan 08, 2026 at 02:24:55PM +0000, Lorenzo Stoakes wrote:
>
> At any rate, even if you feel this is exactly the same, you surely therefore
> cannot object to the suggested changes in [0] which would amount in your view
> then to the same kind of dismissal you might give to a checkpatch --fix series?
I have no problem with the suggested changes. I am especially happy that
they say "As with the output of any tooling".
--
MST
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-08 14:35 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: James Bottomley, 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: <20260108092635-mutt-send-email-mst@kernel.org>
On Thu, Jan 08, 2026 at 09:28:09AM -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 08, 2026 at 02:24:55PM +0000, Lorenzo Stoakes wrote:
> >
> > At any rate, even if you feel this is exactly the same, you surely therefore
> > cannot object to the suggested changes in [0] which would amount in your view
> > then to the same kind of dismissal you might give to a checkpatch --fix series?
>
> I have no problem with the suggested changes. I am especially happy that
> they say "As with the output of any tooling".
See? I can compromise... ;)
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Julia Lawall @ 2026-01-08 14:48 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: James Bottomley, 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,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260108085215-mutt-send-email-mst@kernel.org>
On Thu, 8 Jan 2026, Michael S. Tsirkin wrote:
> On Thu, Jan 08, 2026 at 08:17:09AM -0500, James Bottomley wrote:
> > > +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.
> >
> > And I thing the addition would apply to any tool used to generate a
> > patch set whether AI or not.
>
> Exactly. I saw my share of "fix checkpatch warning" slop. This is no
> different.
I guess that most maintainers can easily recognize a patch that was
motivated by checkpatch, Coccinelle, smatch etc. Then the review can be
informed by previous experience with the tool. Will the same be the case
for AI? Or does it not matter?
julia
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Michael S. Tsirkin @ 2026-01-08 15:01 UTC (permalink / raw)
To: Julia Lawall
Cc: James Bottomley, 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,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <6041b4b8-303a-f12b-24ea-92b836b7a025@inria.fr>
On Thu, Jan 08, 2026 at 03:48:14PM +0100, Julia Lawall wrote:
>
>
> On Thu, 8 Jan 2026, Michael S. Tsirkin wrote:
>
> > On Thu, Jan 08, 2026 at 08:17:09AM -0500, James Bottomley wrote:
> > > > +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.
> > >
> > > And I thing the addition would apply to any tool used to generate a
> > > patch set whether AI or not.
> >
> > Exactly. I saw my share of "fix checkpatch warning" slop. This is no
> > different.
>
> I guess that most maintainers can easily recognize a patch that was
> motivated by checkpatch, Coccinelle, smatch etc. Then the review can be
> informed by previous experience with the tool. Will the same be the case
> for AI? Or does it not matter?
>
> julia
It is not the issue that checkpatch motivated something. The issue is
that a lot of people don't understand that "checkpatch complained" is
not motivation enough to make a change. I expect this holds for all
tools.
--
MST
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: James Bottomley @ 2026-01-08 15:58 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, Sasha Levin, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <85614f7f-f217-47e5-a9f7-0a012f6e6ecd@lucifer.local>
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
+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
^ 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