Patch pre-submission to Sashiko

Patch pre-submission to Sashiko

[Jiri Kosina]

[ in the spirit of the concluding discussion at this year's maintainers 
  summit,  I'm using this list outside of actual maintainer summit 
  planning :) ]

I have just received a v1 to v11 patchset submission within roughly one 
day timeframe.

Neither myself nor anyone else did comment with any review feedback, 
except for Sashiko. Which I believe is what triggered all the immediate 
resubmissions.

I don't think this is sustanable.

The idea of throttling Sashiko's responses was gently nibbled at the 
summit, and might be one of the options how to deal with this.

Another option I'd like to propose would be to introduce a way for 
submitters to run patches through back-and-forth with Sashiko even before 
properly submitting the Sashiko-polished v1 to maintainers and 
mailinglists.

Would that be possible and reasonable?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: Patch pre-submission to Sashiko

[Theodore Tso]

On Sat, Oct 17, 2026 at 07:28:48PM -0500, Jiri Kosina wrote:
> I have just received a v1 to v11 patchset submission within roughly one 
> day timeframe.
> 
> Neither myself nor anyone else did comment with any review feedback, 
> except for Sashiko. Which I believe is what triggered all the immediate 
> resubmissions.

What some subsystem maintainers have requested is delay sashiko
reviews from being sent out by some fixed time, such as 24 hours.

One approach which might want to explore is an exponential backoff.

> Another option I'd like to propose would be to introduce a way for 
> submitters to run patches through back-and-forth with Sashiko even before 
> properly submitting the Sashiko-polished v1 to maintainers and 
> mailinglists.

It's not that hard for people to set up a local Sashiko. and then use
either an local LLM, or their own cloud-hosted AI tokens.  Perhaps
that's something we can encourage.

						- Ted

Re: Patch pre-submission to Sashiko

[johannes.goede]

Hi Ted,

On 17-Oct-26 8:02 PM, Theodore Tso wrote:
> On Sat, Oct 17, 2026 at 07:28:48PM -0500, Jiri Kosina wrote:
>> I have just received a v1 to v11 patchset submission within roughly one 
>> day timeframe.
>>
>> Neither myself nor anyone else did comment with any review feedback, 
>> except for Sashiko. Which I believe is what triggered all the immediate 
>> resubmissions.
> 
> What some subsystem maintainers have requested is delay sashiko
> reviews from being sent out by some fixed time, such as 24 hours.
> 
> One approach which might want to explore is an exponential backoff.
> 
>> Another option I'd like to propose would be to introduce a way for 
>> submitters to run patches through back-and-forth with Sashiko even before 
>> properly submitting the Sashiko-polished v1 to maintainers and 
>> mailinglists.
> 
> It's not that hard for people to set up a local Sashiko. and then use
> either an local LLM, or their own cloud-hosted AI tokens.  Perhaps
> that's something we can encourage.

Actually it is that hard. Even if you spend the 2000 - 3000usd
necessary to run somewhat large-ish models locally the results are
still quite slow (which by itself would be ok) and they catch
a lot less then the actual Shashiko service.

As for using "their own cloud-hosted AI tokens" I've not tried this
myself but other people with a personal "Pro" level subscription
have tried and they got blocked out of further token use for 5 hours
(throttled) after a single Shashiko review run on a 5 patch patch-
series.

So it is actually quite hard to get Shashiko to do a pre-check without
just sending of the patches to the list and the Shahiko service do
its thing.

Regards,

Hans

Re: Patch pre-submission to Sashiko

[Theodore Tso]

On Mon, Oct 19, 2026 at 01:02:55PM -0500, johannes.goede@oss.qualcomm.com wrote:
> > It's not that hard for people to set up a local Sashiko. and then use
> > either an local LLM, or their own cloud-hosted AI tokens.  Perhaps
> > that's something we can encourage.
> 
> Actually it is that hard. Even if you spend the 2000 - 3000usd
> necessary to run somewhat large-ish models locally the results are
> still quite slow (which by itself would be ok) and they catch
> a lot less then the actual Shashiko service.

I was thinking about difficulty in setting up, but it's fair to point
out that not everyone will have access to a high-end GPU or a M5 Max
or RTX/DGX Spark setup.  On the other hand, not everyone is going to
big development/build machine. either.

So we might need to consider what a hobbyist or student might have
access to, versus a corproate-sponsored emplyoee/contractor at
different companies, etc.  The former might only have a personal "Pro"
level subscription, but some other folks might have company sponsored
token budgets which even in the post-token-maxxing era, might be a bit
more generous than a subscription plan.

As someone else has pointed out, students / hobbyists just use
OpenCode with the review prompts with one of their free models, such
as "Big Pickle".  That or a local quen3-coder-next (my current local
LLM, when I'm not using my employer's cloud hosted models) might not
be as good as Sashiko, but you can find a lot of the obvious issues
first, before you send it to the public list.

	       	      	       	     	 - Ted

Re: Patch pre-submission to Sashiko

[Bart Van Assche]

On 10/19/26 1:27 PM, Theodore Tso wrote:
> As someone else has pointed out, students / hobbyists just use
> OpenCode with the review prompts with one of their free models, such
> as "Big Pickle".  That or a local quen3-coder-next (my current local
> LLM, when I'm not using my employer's cloud hosted models) might not
> be as good as Sashiko, but you can find a lot of the obvious issues
> first, before you send it to the public list.

Does the requirement to run a local LLM raise the barrier to start with
kernel coding? The following approach is not as good as running Sashiko
locally but can help those who can't run an LLM locally:
* Open the website of your favorite LLM.
* Enter the prompt "Create a prompt for performing a Sashiko-style Linux 
kernel patch review. In this context Sashiko refers to 
https://github.com/sashiko-dev/sashiko"
* Copy/paste the generated prompt. Do not submit it yet.
* Copy/paste the patches that should be reviewed into the LLM web
   browser session, e.g. with git format-patch ...; cat *.patch | wl-copy
* Submit the review prompt + patches to the LLM and let the LLM review
   your code.

Bart.

Re: Patch pre-submission to Sashiko

[Theodore Tso]

On Tue, Oct 20, 2026 at 07:20:53AM -0500, Bart Van Assche wrote:
> 
> Does the requirement to run a local LLM raise the barrier to start with
> kernel coding?

What I was proposing was an expectation that *if* you are using an LLM
to do kernel coding, best practices would include requiring the LLM
performing the agentic coding loop to do the following:

   * Validate the commit using checkpatch
   * Do a test compile
   * Run any relevant kunit or kselftests
   * Run the commit via an Agentic review system

and maybe even:

   * Add a kunit test covering any changes made by the agentically
     generated code.

If someone wants to send a 100% human-crafted code, today we strongly
suggest (but don't absolutely require) that people at least run
checkpatch, and to read, mark, learn, and inwardly digest (with
apologies to Thomas Cranmer) the rules in SubmittingPatches.  I've in
the past requested that people at *least* run "kvm-xfstests smoke",
but that hasn't been particularly successful.  Should we ask that
human code contributors do more, such as running kunit tests?
Perhaps.

Given that code contributors vastly outnumber maintainers and
reviewerrs, it seems that anything we can do to request that people
generating load on the maintainers and reviewers take at least some
steps to make our lives easier.

						- Ted

P.S.  Ideally I'd love it if we could ask people to run either
"kvm-xfstests -c ext4/4k -g auto" for all ext4 patches, but that would
take 1-2 hours on their development machine, or run "gce-xfstests -c
ext4/4k -g auto", but that would require that they have a Google
Compute Engine account and be willing to spend $0.25 USD.  That's
probably unreasonable, but a maintainer can dream.  :-)

Re: Patch pre-submission to Sashiko

[Miguel Ojeda]

On Tue, Oct 20, 2026 at 9:23 PM Theodore Tso <tytso@mit.edu> wrote:
>
> but that hasn't been particularly successful.  Should we ask that
> human code contributors do more, such as running kunit tests?
> Perhaps.

I think KUnit is a reasonable ask -- in Rust we already essentially
require it, because examples in docs are transformed into KUnit tests
there, and we ask people to write examples for new APIs.

Cheers,
Miguel

Re: Patch pre-submission to Sashiko

[Shuah Khan]

On 10/20/26 13:21, Theodore Tso wrote:
> On Tue, Oct 20, 2026 at 07:20:53AM -0500, Bart Van Assche wrote:
>>
>> Does the requirement to run a local LLM raise the barrier to start with
>> kernel coding?
> 
> What I was proposing was an expectation that *if* you are using an LLM
> to do kernel coding, best practices would include requiring the LLM
> performing the agentic coding loop to do the following:
> 
>     * Validate the commit using checkpatch
>     * Do a test compile
>     * Run any relevant kunit or kselftests
>     * Run the commit via an Agentic review system

A couple of more:

Explain how the problem was found
Explain why the change is needed

> 
> and maybe even:
> 
>     * Add a kunit test covering any changes made by the agentically
>       generated code.

kunit or kselftest covering any changes made by the agentically
generated code

> 
> If someone wants to send a 100% human-crafted code, today we strongly
> suggest (but don't absolutely require) that people at least run
> checkpatch, and to read, mark, learn, and inwardly digest (with
> apologies to Thomas Cranmer) the rules in SubmittingPatches.  I've in
> the past requested that people at *least* run "kvm-xfstests smoke",
> but that hasn't been particularly successful.  Should we ask that
> human code contributors do more, such as running kunit tests?
> Perhaps.

I think it makes perfect sense to ask people to run tests. How else
would they know their fix/change works and doesn't introduce
regressions?

> 
> Given that code contributors vastly outnumber maintainers and
> reviewerrs, it seems that anything we can do to request that people
> generating load on the maintainers and reviewers take at least some
> steps to make our lives easier.

Contributors vastly outnumber maintainers and reviewers and this
is why it is important for us to ask contributors to do their
part in verify their contributions.

thanks,
-- Shuah

Re: Patch pre-submission to Sashiko

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

On Tue, Oct 20, 2026 at 02:43:27PM -0600, Shuah Khan wrote:
> On 10/20/26 13:21, Theodore Tso wrote:

> > and maybe even:

> >     * Add a kunit test covering any changes made by the agentically
> >       generated code.

> kunit or kselftest covering any changes made by the agentically
> generated code

TBH having seen some LLM patches that come with LLM generated testcases
the testcases are much worse than the patches themselves.  Open coding,
weird structures, asserting bizzare things without explanation - just
generally really hard to understand what the test is trying to
accomplish and why.  Sometimes for a one and done test, especially one
you're not going to keep around, it doesn't matter so much but stuff
like that can really impact the maintainability of the testuite.  Some
of this is probably submitters paying comparatively less attention to
the tests and just throwing anything over the wall without review.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Patch pre-submission to Sashiko

[Theodore Tso]

On Wed, Oct 21, 2026 at 12:07:09PM -0500, Mark Brown wrote:
> 
> TBH having seen some LLM patches that come with LLM generated testcases
> the testcases are much worse than the patches themselves.  Open coding,
> weird structures, asserting bizzare things without explanation - just
> generally really hard to understand what the test is trying to
> accomplish and why.

I recently posted a patch[1] to add KUnit tests for
fs/ext4/extents_status.c.  It was completely AI generated, and used
these instructions which I gave to Gemini Pro[2].

[1] https://lore.kernel.org/all/20261021031231.40107-1-tytso@mit.edu/
[2] https://lore.kernel.org/all/atbZWze194QiSOTe@mit.edu/

I'm obviously biased, but it seems to me these test cases were pretty
good.  I'd appreciate criticisms and suggestions for improvements, but
if your experience is test cases written with older models, the latest
frontier models have gotten way better.

Cheers,

					- Ted

Re: Patch pre-submission to Sashiko

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

On Wed, Oct 21, 2026 at 12:20:43PM -0400, Theodore Tso wrote:
> On Wed, Oct 21, 2026 at 12:07:09PM -0500, Mark Brown wrote:

> > TBH having seen some LLM patches that come with LLM generated testcases
> > the testcases are much worse than the patches themselves.  Open coding,
> > weird structures, asserting bizzare things without explanation - just
> > generally really hard to understand what the test is trying to
> > accomplish and why.

> I recently posted a patch[1] to add KUnit tests for
> fs/ext4/extents_status.c.  It was completely AI generated, and used
> these instructions which I gave to Gemini Pro[2].

> [1] https://lore.kernel.org/all/20261021031231.40107-1-tytso@mit.edu/
> [2] https://lore.kernel.org/all/atbZWze194QiSOTe@mit.edu/

> I'm obviously biased, but it seems to me these test cases were pretty
> good.  I'd appreciate criticisms and suggestions for improvements, but
> if your experience is test cases written with older models, the latest
> frontier models have gotten way better.

Yeah, it's not that you can't do it but rather that I'm nervous of how
much of a useful gate it is to require tests - my general feel is that
if the commits have problems then any associated tests tend to have more
problems.  One example I reviewed earlier today is here:

   https://lore.kernel.org/r/ed22ebf64ed00a56d5e1eff31ac639fef00dcae6.1792179433.git.ivanrwcm25@gmail.com

which will get the issue it was looking for but isn't something I'd want
to maintain long term.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Patch pre-submission to Sashiko

[Andrew Morton]

On Wed, 21 Oct 2026 17:33:15 +0100 Mark Brown <broonie@kernel.org> wrote:

> On Wed, Oct 21, 2026 at 12:20:43PM -0400, Theodore Tso wrote:
> > On Wed, Oct 21, 2026 at 12:07:09PM -0500, Mark Brown wrote:
> 
> > > TBH having seen some LLM patches that come with LLM generated testcases
> > > the testcases are much worse than the patches themselves.  Open coding,
> > > weird structures, asserting bizzare things without explanation - just
> > > generally really hard to understand what the test is trying to
> > > accomplish and why.
> 
> > I recently posted a patch[1] to add KUnit tests for
> > fs/ext4/extents_status.c.  It was completely AI generated, and used
> > these instructions which I gave to Gemini Pro[2].
> 
> > [1] https://lore.kernel.org/all/20261021031231.40107-1-tytso@mit.edu/
> > [2] https://lore.kernel.org/all/atbZWze194QiSOTe@mit.edu/
> 
> > I'm obviously biased, but it seems to me these test cases were pretty
> > good.  I'd appreciate criticisms and suggestions for improvements, but
> > if your experience is test cases written with older models, the latest
> > frontier models have gotten way better.
> 
> Yeah, it's not that you can't do it but rather that I'm nervous of how
> much of a useful gate it is to require tests - my general feel is that
> if the commits have problems then any associated tests tend to have more
> problems.  One example I reviewed earlier today is here:
> 
>    https://lore.kernel.org/r/ed22ebf64ed00a56d5e1eff31ac639fef00dcae6.1792179433.git.ivanrwcm25@gmail.com
> 
> which will get the issue it was looking for but isn't something I'd want
> to maintain long term.

If someone's fixing something I don't see much value in
retaining/maintaining a test case for something we've already fixed. 
This is considered good engineering practice but why bother - we fixed
it!  Move on.

It is good to see testcases during the fixing process though.  In these
cases I prefer that the test code be included below the --- with a
brief mention in the main changelog.  So interested people can later
chase down the Link: and find the test code.

Re: Patch pre-submission to Sashiko

[Rafael J. Wysocki (Intel)]

On Wed, Oct 21, 2026 at 8:45 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 21 Oct 2026 17:33:15 +0100 Mark Brown <broonie@kernel.org> wrote:
>
> > On Wed, Oct 21, 2026 at 12:20:43PM -0400, Theodore Tso wrote:
> > > On Wed, Oct 21, 2026 at 12:07:09PM -0500, Mark Brown wrote:
> >
> > > > TBH having seen some LLM patches that come with LLM generated testcases
> > > > the testcases are much worse than the patches themselves.  Open coding,
> > > > weird structures, asserting bizzare things without explanation - just
> > > > generally really hard to understand what the test is trying to
> > > > accomplish and why.
> >
> > > I recently posted a patch[1] to add KUnit tests for
> > > fs/ext4/extents_status.c.  It was completely AI generated, and used
> > > these instructions which I gave to Gemini Pro[2].
> >
> > > [1] https://lore.kernel.org/all/20261021031231.40107-1-tytso@mit.edu/
> > > [2] https://lore.kernel.org/all/atbZWze194QiSOTe@mit.edu/
> >
> > > I'm obviously biased, but it seems to me these test cases were pretty
> > > good.  I'd appreciate criticisms and suggestions for improvements, but
> > > if your experience is test cases written with older models, the latest
> > > frontier models have gotten way better.
> >
> > Yeah, it's not that you can't do it but rather that I'm nervous of how
> > much of a useful gate it is to require tests - my general feel is that
> > if the commits have problems then any associated tests tend to have more
> > problems.  One example I reviewed earlier today is here:
> >
> >    https://lore.kernel.org/r/ed22ebf64ed00a56d5e1eff31ac639fef00dcae6.1792179433.git.ivanrwcm25@gmail.com
> >
> > which will get the issue it was looking for but isn't something I'd want
> > to maintain long term.
>
> If someone's fixing something I don't see much value in
> retaining/maintaining a test case for something we've already fixed.
> This is considered good engineering practice but why bother - we fixed
> it!  Move on.
>
> It is good to see testcases during the fixing process though.  In these
> cases I prefer that the test code be included below the --- with a
> brief mention in the main changelog.  So interested people can later
> chase down the Link: and find the test code.

Exactly my thoughts on both points, thank you!

Re: Patch pre-submission to Sashiko

[Theodore Tso]

On Wed, Oct 21, 2026 at 11:45:24AM -0500, Andrew Morton wrote:
> 
> If someone's fixing something I don't see much value in
> retaining/maintaining a test case for something we've already fixed. 
> This is considered good engineering practice but why bother - we fixed
> it!  Move on.

It's considered good engineering practice because regularly running
the test allows regresssions to be detected, and by increasing test
coverage, it makes life easier to feel confident that a future code
change, or rebase, is ultimately correct.

Of course, you need to do the cost/benefit tradeoff.  If the test
takes a very long time to run, or if maintaining it requires a huge
amount of code outside of the test, then it could be that the benefits
aren't worth the on-going costs of keeping the test around.

This is one of the reasons why I'm a big fan of unit testing.  The
unit tests tend to run much more quickly than integration-style tests.

     	   	       	    	 - Ted

Re: Patch pre-submission to Sashiko

[Jiri Kosina]

On Wed, 21 Oct 2026, Andrew Morton wrote:

> If someone's fixing something I don't see much value in
> retaining/maintaining a test case for something we've already fixed. 

There are engineering methodologies which suggest exactly the contrary, 
i.e. to make good use of the fact that we had a bug to add test for, to 
make sure that we never ever regress on it again.

I can come up with quite a few examples where we broke something more than 
once in a row.

-- 
Jiri Kosina
SUSE Labs

Re: Patch pre-submission to Sashiko

[Steven Rostedt]

On Wed, 21 Oct 2026 22:10:18 +0200 (CEST)
Jiri Kosina <jikos@kernel.org> wrote:

> On Wed, 21 Oct 2026, Andrew Morton wrote:
> 
> > If someone's fixing something I don't see much value in
> > retaining/maintaining a test case for something we've already fixed.   
> 
> There are engineering methodologies which suggest exactly the contrary, 
> i.e. to make good use of the fact that we had a bug to add test for, to 
> make sure that we never ever regress on it again.
> 
> I can come up with quite a few examples where we broke something more than 
> once in a row.

I try to add tests to most bugs I fix to make sure the tests catch it the
next time. My experience, they catch something a few years later, because
code gets modified and old bugs resurface. Hence, why I want those tests.

-- Steve

Re: Patch pre-submission to Sashiko

[Paul E. McKenney]

On Wed, Oct 21, 2026 at 11:45:24AM -0700, Andrew Morton wrote:
> On Wed, 21 Oct 2026 17:33:15 +0100 Mark Brown <broonie@kernel.org> wrote:
> 
> > On Wed, Oct 21, 2026 at 12:20:43PM -0400, Theodore Tso wrote:
> > > On Wed, Oct 21, 2026 at 12:07:09PM -0500, Mark Brown wrote:
> > 
> > > > TBH having seen some LLM patches that come with LLM generated testcases
> > > > the testcases are much worse than the patches themselves.  Open coding,
> > > > weird structures, asserting bizzare things without explanation - just
> > > > generally really hard to understand what the test is trying to
> > > > accomplish and why.
> > 
> > > I recently posted a patch[1] to add KUnit tests for
> > > fs/ext4/extents_status.c.  It was completely AI generated, and used
> > > these instructions which I gave to Gemini Pro[2].
> > 
> > > [1] https://lore.kernel.org/all/20261021031231.40107-1-tytso@mit.edu/
> > > [2] https://lore.kernel.org/all/atbZWze194QiSOTe@mit.edu/
> > 
> > > I'm obviously biased, but it seems to me these test cases were pretty
> > > good.  I'd appreciate criticisms and suggestions for improvements, but
> > > if your experience is test cases written with older models, the latest
> > > frontier models have gotten way better.
> > 
> > Yeah, it's not that you can't do it but rather that I'm nervous of how
> > much of a useful gate it is to require tests - my general feel is that
> > if the commits have problems then any associated tests tend to have more
> > problems.  One example I reviewed earlier today is here:
> > 
> >    https://lore.kernel.org/r/ed22ebf64ed00a56d5e1eff31ac639fef00dcae6.1792179433.git.ivanrwcm25@gmail.com
> > 
> > which will get the issue it was looking for but isn't something I'd want
> > to maintain long term.
> 
> If someone's fixing something I don't see much value in
> retaining/maintaining a test case for something we've already fixed. 
> This is considered good engineering practice but why bother - we fixed
> it!  Move on.
> 
> It is good to see testcases during the fixing process though.  In these
> cases I prefer that the test code be included below the --- with a
> brief mention in the main changelog.  So interested people can later
> chase down the Link: and find the test code.

The "right" thing to do is to work the new testing needs into existing
tests.  Of course, this is often a bit harder than it looks.  But when
this can be made to work, you get increased coverage for the same
testing resources.

Pity about the added development costs.  ;-)

							Thanx, Paul

Re: Patch pre-submission to Sashiko

[Alexei Starovoitov]

On Sat Oct 17, 2026 at 5:28 PM UTC, Jiri Kosina wrote:
>
> [ in the spirit of the concluding discussion at this year's maintainers 
>   summit,  I'm using this list outside of actual maintainer summit 
>   planning :) ]
>
> I have just received a v1 to v11 patchset submission within roughly one 
> day timeframe.
>
> Neither myself nor anyone else did comment with any review feedback, 
> except for Sashiko. Which I believe is what triggered all the immediate 
> resubmissions.
>
> I don't think this is sustanable.

I think it's just fine. I encourage developers to keep the spam going.

You can simulate github style squah of v1->v2->v3 in your inbox.
Ask your agent to monitor inbox, archive vN when vN+1 arrives
and summarize v1->vN discussion. Then you'll always have the latest
patch set to look at and a summary of what happened when you were away.
Then sit on it for a day or a week to see whether respin
cycle has ended (and bots stopped talking to each other) and then
do a human part of maintainership.

Re: Patch pre-submission to Sashiko

[Arnaldo Melo]

On October 17, 2026 3:20:47 PM GMT-03:00, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>On Sat Oct 17, 2026 at 5:28 PM UTC, Jiri Kosina wrote:
>>
>> [ in the spirit of the concluding discussion at this year's maintainers 
>>   summit,  I'm using this list outside of actual maintainer summit 
>>   planning :) ]
>>
>> I have just received a v1 to v11 patchset submission within roughly one 
>> day timeframe.
>>
>> Neither myself nor anyone else did comment with any review feedback, 
>> except for Sashiko. Which I believe is what triggered all the immediate 
>> resubmissions.
>>
>> I don't think this is sustanable.
>
>I think it's just fine. I encourage developers to keep the spam going.

Yay, agreed, it's not like before AI people were reading all of lkml (or other voluminous lists) traffic, just ignore what clearly is a conversation that now happens way faster than in the past until you see it calmed down 

The problem was not getting feedback at all, now people complain that feedback is being provided timely and then that people are responding to feedback in a timely fashion?

>You can simulate github style squah of v1->v2->v3 in your inbox.
>Ask your agent to monitor inbox, archive vN when vN+1 arrives
>and summarize v1->vN discussion. Then you'll always have the latest
>patch set to look at and a summary of what happened when you were away.
>Then sit on it for a day or a week to see whether respin
>cycle has ended (and bots stopped talking to each other) and then
>do a human part of maintainership.

+5, +1 is not enough 8-)

Fight fire with fire,  more is good, if it's too much look just at the latest patch series version when you think it slowed down. Or, if not allergic to AI, use it to summarize the previous discussion, human or trained on human data one.

When not understanding about some specific part of the latest version maybe looking at the "churn" will provide all the details you need.

- Arnaldo

Re: Patch pre-submission to Sashiko

[Dan Carpenter]

On Sat, Oct 17, 2026 at 03:38:36PM -0300, Arnaldo Melo wrote:
> 
> 
> On October 17, 2026 3:20:47 PM GMT-03:00, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >On Sat Oct 17, 2026 at 5:28 PM UTC, Jiri Kosina wrote:
> >>
> >> [ in the spirit of the concluding discussion at this year's maintainers 
> >>   summit,  I'm using this list outside of actual maintainer summit 
> >>   planning :) ]
> >>
> >> I have just received a v1 to v11 patchset submission within roughly one 
> >> day timeframe.
> >>
> >> Neither myself nor anyone else did comment with any review feedback, 
> >> except for Sashiko. Which I believe is what triggered all the immediate 
> >> resubmissions.
> >>
> >> I don't think this is sustanable.
> >
> >I think it's just fine. I encourage developers to keep the spam going.
> 
> Yay, agreed, it's not like before AI people were reading all of lkml

I read everything that's sent to drivers/staging.  I've read it in the
order that it arrives and I've done that since 2010...  But these days
people are treating the list like a pre-submit AI checker which sucks.
I feel like people are saying we should just accept that mailing lists
are just AI checker interfaces instead of being intended for humans...

I think adding a 24 hour delay to the AI review solves this.  It seems
to be working for networking.  It will likely push people to use AI
locally which is even better.

> (or other voluminous lists) traffic, just ignore what clearly is a
> conversation that now happens way faster than in the past until you
> see it calmed down 
> 
> The problem was not getting feedback at all, now people complain that
> feedback is being provided timely and then that people are responding
> to feedback in a timely fashion?

That has never been a problem on drivers/staging.  Greg responds
to every email and when he was on vacation then I responded to
every email.

regards,
dan carpenter

Re: Patch pre-submission to Sashiko

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

On Sat, Oct 17, 2026 at 06:20:47PM +0000, Alexei Starovoitov wrote:
> On Sat Oct 17, 2026 at 5:28 PM UTC, Jiri Kosina wrote:

> > Neither myself nor anyone else did comment with any review feedback, 
> > except for Sashiko. Which I believe is what triggered all the immediate 
> > resubmissions.

> > I don't think this is sustanable.

> I think it's just fine. I encourage developers to keep the spam going.

> You can simulate github style squah of v1->v2->v3 in your inbox.
> Ask your agent to monitor inbox, archive vN when vN+1 arrives
> and summarize v1->vN discussion. Then you'll always have the latest
> patch set to look at and a summary of what happened when you were away.
> Then sit on it for a day or a week to see whether respin
> cycle has ended (and bots stopped talking to each other) and then
> do a human part of maintainership.

It's not just LLM users getting caught by this, I've seen people I know
going multiple rounds in what appears to be a very human fashion trying
to shut the warnings up.  Given that some maintainers won't look at
anything until all Sashiko is happy it's a totally reasonable thing to
do but I can't imagine it's an inspiring experience.  A lot of that has
been with valid but not interesting or useful issues (the stereotypical
example is something like missing return value checks on a MMIO regmap).
Even with people who appear to be LLM users I've seen people going all
weekend with no human review only to find that the first human review is
that the approach is completely wrong and they were wasting their time
fixing the detail issues that were being flagged which I can't imagine
is especially pleasant.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Patch pre-submission to Sashiko

[Linus Torvalds]

On Sat, 17 Oct 2026 at 07:39, Jiri Kosina <jikos@kernel.org> wrote:
>
> Another option I'd like to propose would be to introduce a way for
> submitters to run patches through back-and-forth with Sashiko even before
> properly submitting the Sashiko-polished v1 to maintainers and
> mailinglists.

I think maybe we should make it really easy for people to run their
some kind of sashiko setup on their own, rather than rely on sashiko
itself. After all, these are all people who use an LLM to begin with.

And assuming they sre starting out, they are probably are *not*
building their own local LLM for this either, so presumably /
hopefully they have a fairly capable LLM setup, and the problem is
primarily lack of kernel knowledge (and possibly LLM background too -
that side was certainly a learnign experience for me).

So maybe at least one piece of the puzzle is us pointing to existing
sashiko (or sashiko-like) rules so that people who use LLM's get the
"basic rules" almost by default, rather than burdening sashiko more.

.. and I do still think that we should have some kind of "sashiko
doesn't answer for 18 hours" kind of limiter. Possibly with some
back-off per submitter (and by patch series size) so that repeated
submissions get spread out even more.

                 Linus

Re: Patch pre-submission to Sashiko

[Roman Gushchin]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sat, 17 Oct 2026 at 07:39, Jiri Kosina <jikos@kernel.org> wrote:
>>
>> Another option I'd like to propose would be to introduce a way for
>> submitters to run patches through back-and-forth with Sashiko even before
>> properly submitting the Sashiko-polished v1 to maintainers and
>> mailinglists.
>
> I think maybe we should make it really easy for people to run their
> some kind of sashiko setup on their own, rather than rely on sashiko
> itself. After all, these are all people who use an LLM to begin with.

It is really easy now:
$ cargo install sashiko
$ sashiko init
set the LLM key
$ cd linux && sashiko review HEAD^5..HEAD

> And assuming they sre starting out, they are probably are *not*
> building their own local LLM for this either, so presumably /
> hopefully they have a fairly capable LLM setup, and the problem is
> primarily lack of kernel knowledge (and possibly LLM background too -
> that side was certainly a learnign experience for me).
>
> So maybe at least one piece of the puzzle is us pointing to existing
> sashiko (or sashiko-like) rules so that people who use LLM's get the
> "basic rules" almost by default, rather than burdening sashiko more.

If we're adding AGENTS.md and/or skills into the kernel tree,
we can add an instruction on how to install and run local sashiko
and instruct agents to do it as the part of the process.
I actually use this for developing sashiko itself, works well.

Also I'm going to add a simple way for maintainers to add subjective
instructions (e.g. "don't send me typo fixes" or "X is frozen, don't add
new features", or "if you touch Y, run Z tests and include results"),
so hopefully it can stop some number of really bad patches before
the mailing list.

> .. and I do still think that we should have some kind of "sashiko
> doesn't answer for 18 hours" kind of limiter. Possibly with some
> back-off per submitter (and by patch series size) so that repeated
> submissions get spread out even more.

It sounds like maintainers have drastically different preferences here,
so I guess a per-mailing list configuration is the only reasonable
setup? I'm trying to be on a conservative side, so e.g. if there is no
consensus between maintainers, I do not enable emails.

Jiri, is it about some specific mailing list? We can enable e.g. 24h
embargo there.

Thanks

Re: Patch pre-submission to Sashiko

[Steven Rostedt]

On Sat, 17 Oct 2026 20:10:44 +0000
Roman Gushchin <roman.gushchin@linux.dev> wrote:

> It sounds like maintainers have drastically different preferences here,
> so I guess a per-mailing list configuration is the only reasonable
> setup? I'm trying to be on a conservative side, so e.g. if there is no
> consensus between maintainers, I do not enable emails.

Right. I have no issue with spamming of sashiko and back. I use
patchwork which is pretty good at only giving me the last version of a
series. And if I see that sashiko made a comment, I would have them
address it before I begin to review the series. Until sashiko is done,
I don't care if they send 11 iterations in a day. It's 11 iterations I
can ignore. In fact, that means I can start looking at it sooner.

As for Andrew's point on testing. I would hope that they would have
tested before sending v1. But sashiko is good at finding things that
tests don't catch. So if they are just fixing sashiko comments, it may
be that their tests are not catching what sashiko is finding. As
sashiko finds new issues with pretty much every new version, I can see
them having to constantly send another version with new info from
sashiko.

-- Steve

Re: Patch pre-submission to Sashiko

[Kees Cook]

On Sat, Oct 17, 2026 at 08:10:44PM +0000, Roman Gushchin wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > On Sat, 17 Oct 2026 at 07:39, Jiri Kosina <jikos@kernel.org> wrote:
> >>
> >> Another option I'd like to propose would be to introduce a way for
> >> submitters to run patches through back-and-forth with Sashiko even before
> >> properly submitting the Sashiko-polished v1 to maintainers and
> >> mailinglists.
> >
> > I think maybe we should make it really easy for people to run their
> > some kind of sashiko setup on their own, rather than rely on sashiko
> > itself. After all, these are all people who use an LLM to begin with.
> 
> It is really easy now:
> $ cargo install sashiko
> $ sashiko init
> set the LLM key
> $ cd linux && sashiko review HEAD^5..HEAD

FWIW, I have been using this for a while now (and making this "local
review" mode more ergonomic). With Anthropic's recent "API credit" stuff,
this works very well with the Haiku model (Opus is outrageous over-kill
and charges you 40x more than haiku).

-- 
Kees Cook

Re: Patch pre-submission to Sashiko

[Linus Torvalds]

On Sun, 18 Oct 2026 at 08:41, Kees Cook <kees@kernel.org> wrote:
>
> On Sat, Oct 17, 2026 at 08:10:44PM +0000, Roman Gushchin wrote:
> > It is really easy now:
> > $ cargo install sashiko
> > $ sashiko init
> > set the LLM key
> > $ cd linux && sashiko review HEAD^5..HEAD
>
> FWIW, I have been using this for a while now (and making this "local
> review" mode more ergonomic). With Anthropic's recent "API credit" stuff,
> this works very well with the Haiku model (Opus is outrageous over-kill
> and charges you 40x more than haiku).

So we just need to make sure that people get this automatically, I think.

Right now you need to *know* to do this. That's a problem when at
least some of the noise comes from people who don't know the kernel,
and don't know where to look.

Hopefully the agent updates will sort some of this out and just mean
that people get a sane baseline.

               Linus

Re: Patch pre-submission to Sashiko

[Oliver Slapinski]

Hi Linus,

I'm working on an opt-in adaptive publication cooldown to address the
rapid-resubmission loop. Suppression of superseded held reviews is
implemented and tested; the adaptive policy is still in progress.

The initial scope is a capped delay based on revision activity,
preserving existing behavior when disabled. Series-size weighting and
cross-posted series are outside this first version.

I've also read your later point about discovering kernel rules and
local-review guidance automatically. That's a separate gap from the
publication limiter.

Thanks,
Oliver

On Sat, 17 Oct 2026 08:20:49 -1000, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sat, 17 Oct 2026 at 07:39, Jiri Kosina <jikos@kernel.org> wrote:
> >
> > Another option I'd like to propose would be to introduce a way for
> > submitters to run patches through back-and-forth with Sashiko even before
> > properly submitting the Sashiko-polished v1 to maintainers and
> > mailinglists.
>
> I think maybe we should make it really easy for people to run their
> some kind of sashiko setup on their own, rather than rely on sashiko
> itself. After all, these are all people who use an LLM to begin with.
>
> And assuming they sre starting out, they are probably are *not*
> building their own local LLM for this either, so presumably /
> hopefully they have a fairly capable LLM setup, and the problem is
> primarily lack of kernel knowledge (and possibly LLM background too -
> that side was certainly a learnign experience for me).
>
> So maybe at least one piece of the puzzle is us pointing to existing
> sashiko (or sashiko-like) rules so that people who use LLM's get the
> "basic rules" almost by default, rather than burdening sashiko more.
>
> .. and I do still think that we should have some kind of "sashiko
> doesn't answer for 18 hours" kind of limiter. Possibly with some
> back-off per submitter (and by patch series size) so that repeated
> submissions get spread out even more.
>
>                  Linus

Re: Patch pre-submission to Sashiko

[Andrew Lunn]

On Sat, Oct 17, 2026 at 07:28:48PM +0200, Jiri Kosina wrote:
> 
> [ in the spirit of the concluding discussion at this year's maintainers 
>   summit,  I'm using this list outside of actual maintainer summit 
>   planning :) ]
> 
> I have just received a v1 to v11 patchset submission within roughly one 
> day timeframe.

If they are iterating that fast, they either have automated tests, or
the code is untested. I would ask them to includes the tests in the
patchset, to become part of tools/testing/selftests.

	  Andrew

Re: Patch pre-submission to Sashiko

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

On Sat, Oct 17, 2026 at 09:42:34PM +0200, Andrew Lunn wrote:
> On Sat, Oct 17, 2026 at 07:28:48PM +0200, Jiri Kosina wrote:

> > I have just received a v1 to v11 patchset submission within roughly one 
> > day timeframe.

> If they are iterating that fast, they either have automated tests, or
> the code is untested. I would ask them to includes the tests in the
> patchset, to become part of tools/testing/selftests.

There's some work (init paths for drivers for example) where it's
perfectly plausible that you can reverify things fast enough to be doing
that.  It's probably a relatively long day, but it's doable.  You're
more likely to hit numbers like that over a weekend though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Patch pre-submission to Sashiko

[Laurent Pinchart]

On Sun, Oct 18, 2026 at 12:54:31PM +0100, Mark Brown wrote:
> On Sat, Oct 17, 2026 at 09:42:34PM +0200, Andrew Lunn wrote:
> > On Sat, Oct 17, 2026 at 07:28:48PM +0200, Jiri Kosina wrote:
> > 
> > > I have just received a v1 to v11 patchset submission within roughly one 
> > > day timeframe.
> > 
> > If they are iterating that fast, they either have automated tests, or
> > the code is untested. I would ask them to includes the tests in the
> > patchset, to become part of tools/testing/selftests.
> 
> There's some work (init paths for drivers for example) where it's
> perfectly plausible that you can reverify things fast enough to be doing
> that.  It's probably a relatively long day, but it's doable.  You're
> more likely to hit numbers like that over a weekend though.

And let's not forget that for most patches touching drivers selftests
are not an option.

-- 
Regards,

Laurent Pinchart

Re: Patch pre-submission to Sashiko

[Krzysztof Kozlowski]

On 17/10/2026 19:28, Jiri Kosina wrote:
> 
> [ in the spirit of the concluding discussion at this year's maintainers 
>   summit,  I'm using this list outside of actual maintainer summit 
>   planning :) ]
> 
> I have just received a v1 to v11 patchset submission within roughly one 
> day timeframe.
> 
> Neither myself nor anyone else did comment with any review feedback, 
> except for Sashiko. Which I believe is what triggered all the immediate 
> resubmissions.
> 
> I don't think this is sustanable.

I think it might be fine to drop usual expectation of one patchset per
24h as long as maintainers can completely ignore patchsets with Sashiko
replies.

If people want to keep bouncing the ball between them and Sashiko, they
should be allowed and then we should be allowed just to silence that
email thread completely.

> 
> The idea of throttling Sashiko's responses was gently nibbled at the 
> summit, and might be one of the options how to deal with this.
> 
> Another option I'd like to propose would be to introduce a way for 
> submitters to run patches through back-and-forth with Sashiko even before 
> properly submitting the Sashiko-polished v1 to maintainers and 
> mailinglists.

I assume you mean they will be running it through Sashiko
infrastructure, so using sponsored tokens. Otherwise that possibility is
already there - you can run Sashiko, just a matter of money.

Best regards,
Krzysztof

Re: Patch pre-submission to Sashiko

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
> I assume you mean they will be running it through Sashiko
> infrastructure, so using sponsored tokens. Otherwise that possibility is
> already there - you can run Sashiko, just a matter of money.

I have a patchset in flight where I *have* been running Sashiko (as
well as lots of self-tests) locally, and then got further feedback on
the list from the public Sashiko which my own run hadn't seen. Twice.

I still need to send v3...

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]

Re: Patch pre-submission to Sashiko

[Michal Simek]

On 10/19/26 09:26, David Woodhouse wrote:
> On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
>> I assume you mean they will be running it through Sashiko
>> infrastructure, so using sponsored tokens. Otherwise that possibility is
>> already there - you can run Sashiko, just a matter of money.
> 
> I have a patchset in flight where I *have* been running Sashiko (as
> well as lots of self-tests) locally, and then got further feedback on
> the list from the public Sashiko which my own run hadn't seen. Twice.
> 
> I still need to send v3...

Isn't it better to create a new mailing list and filter all CCs/To?
People can send patches to that mailing list and get reply without CCing 
maintainers and mailing lists. They can run a lot of iterations like that.
When it is clear they can send clear v1 in a normal way.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs

Re: Patch pre-submission to Sashiko

[Julia Lawall]

On Mon, 19 Oct 2026, Michal Simek wrote:

>
>
> On 10/19/26 09:26, David Woodhouse wrote:
> > On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
> > > I assume you mean they will be running it through Sashiko
> > > infrastructure, so using sponsored tokens. Otherwise that possibility is
> > > already there - you can run Sashiko, just a matter of money.
> >
> > I have a patchset in flight where I *have* been running Sashiko (as
> > well as lots of self-tests) locally, and then got further feedback on
> > the list from the public Sashiko which my own run hadn't seen. Twice.
> >
> > I still need to send v3...
>
> Isn't it better to create a new mailing list and filter all CCs/To?
> People can send patches to that mailing list and get reply without CCing
> maintainers and mailing lists. They can run a lot of iterations like that.
> When it is clear they can send clear v1 in a normal way.

This isn't just free tokens for anyone who wants to make a change to the
Linux kernel, not necessarily a change that will ever be sent to a
maintainer?

julia

>
> Thanks,
> Michal
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze
> Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
> U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
> TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
>
>
>

Re: Patch pre-submission to Sashiko

[Michal Simek]

On 10/19/26 14:02, Julia Lawall wrote:
> 
> 
> On Mon, 19 Oct 2026, Michal Simek wrote:
> 
>>
>>
>> On 10/19/26 09:26, David Woodhouse wrote:
>>> On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
>>>> I assume you mean they will be running it through Sashiko
>>>> infrastructure, so using sponsored tokens. Otherwise that possibility is
>>>> already there - you can run Sashiko, just a matter of money.
>>>
>>> I have a patchset in flight where I *have* been running Sashiko (as
>>> well as lots of self-tests) locally, and then got further feedback on
>>> the list from the public Sashiko which my own run hadn't seen. Twice.
>>>
>>> I still need to send v3...
>>
>> Isn't it better to create a new mailing list and filter all CCs/To?
>> People can send patches to that mailing list and get reply without CCing
>> maintainers and mailing lists. They can run a lot of iterations like that.
>> When it is clear they can send clear v1 in a normal way.
> 
> This isn't just free tokens for anyone who wants to make a change to the
> Linux kernel, not necessarily a change that will ever be sent to a
> maintainer?
Isn't this something what people can do even now? They will only keep mailing 
list and maintainer in CC.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs

Re: Patch pre-submission to Sashiko

[Julia Lawall]

> On 19 Oct 2026, at 08:46, Michal Simek <monstr@monstr.eu> wrote:
> 
> 
> 
>> On 10/19/26 14:02, Julia Lawall wrote:
>>> On Mon, 19 Oct 2026, Michal Simek wrote:
>>> 
>>> 
>>> On 10/19/26 09:26, David Woodhouse wrote:
>>>> On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
>>>>> I assume you mean they will be running it through Sashiko
>>>>> infrastructure, so using sponsored tokens. Otherwise that possibility is
>>>>> already there - you can run Sashiko, just a matter of money.
>>>> 
>>>> I have a patchset in flight where I *have* been running Sashiko (as
>>>> well as lots of self-tests) locally, and then got further feedback on
>>>> the list from the public Sashiko which my own run hadn't seen. Twice.
>>>> 
>>>> I still need to send v3...
>>> 
>>> Isn't it better to create a new mailing list and filter all CCs/To?
>>> People can send patches to that mailing list and get reply without CCing
>>> maintainers and mailing lists. They can run a lot of iterations like that.
>>> When it is clear they can send clear v1 in a normal way.
>> This isn't just free tokens for anyone who wants to make a change to the
>> Linux kernel, not necessarily a change that will ever be sent to a
>> maintainer?
> Isn't this something what people can do even now? They will only keep mailing list and maintainer in CC.

There is still the illusion that the code risks ending up in the kernel. I guess that even with the Sashiko only list the code is still public, so perhaps that is dissuasive.


> 
> Thanks,
> Michal
> 
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze
> Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
> U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
> TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
> 

Re: Patch pre-submission to Sashiko

[Rodrigo Vivi]

On Mon, Oct 19, 2026 at 08:57:23AM -0400, Julia Lawall wrote:
> 
> 
> > On 19 Oct 2026, at 08:46, Michal Simek <monstr@monstr.eu> wrote:
> > 
> > 
> > 
> >> On 10/19/26 14:02, Julia Lawall wrote:
> >>> On Mon, 19 Oct 2026, Michal Simek wrote:
> >>> 
> >>> 
> >>> On 10/19/26 09:26, David Woodhouse wrote:
> >>>> On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
> >>>>> I assume you mean they will be running it through Sashiko
> >>>>> infrastructure, so using sponsored tokens. Otherwise that possibility is
> >>>>> already there - you can run Sashiko, just a matter of money.
> >>>> 
> >>>> I have a patchset in flight where I *have* been running Sashiko (as
> >>>> well as lots of self-tests) locally, and then got further feedback on
> >>>> the list from the public Sashiko which my own run hadn't seen. Twice.
> >>>> 
> >>>> I still need to send v3...
> >>> 
> >>> Isn't it better to create a new mailing list and filter all CCs/To?
> >>> People can send patches to that mailing list and get reply without CCing
> >>> maintainers and mailing lists. They can run a lot of iterations like that.
> >>> When it is clear they can send clear v1 in a normal way.
> >> This isn't just free tokens for anyone who wants to make a change to the
> >> Linux kernel, not necessarily a change that will ever be sent to a
> >> maintainer?
> > Isn't this something what people can do even now? They will only keep mailing list and maintainer in CC.
> 
> There is still the illusion that the code risks ending up in the kernel. I guess that even with the Sashiko only list the code is still public, so perhaps that is dissuasive.

Perhaps if there was some way to point out to Sashiko where the github for that
series is and some button to request redo-review, then the polution on the
mailing list doesn't exist while dev isn't sure that the Sashiko is okay
with the changes.

The problem with this idea might be the abuse of the tokens indeed.

I also believe that the delayed Sashiko response is not good and it only
makes the pain longer.

Local runs of Sashiko might also not cover everything because of tokens
or models limitation. Then, there will always be the risk of local limited
setup not catching the same things and the loop in public mailing list to
continue.

> 
> 
> > 
> > Thanks,
> > Michal
> > 
> > --
> > Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> > w: www.monstr.eu p: +42-0-721842854
> > Maintainer of Linux kernel - Xilinx Microblaze
> > Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
> > U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
> > TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
> > 
> 
> 

Re: Patch pre-submission to Sashiko

[Shuah Khan]

On 10/19/26 00:25, Krzysztof Kozlowski wrote:
> On 17/10/2026 19:28, Jiri Kosina wrote:
>>
>> [ in the spirit of the concluding discussion at this year's maintainers
>>    summit,  I'm using this list outside of actual maintainer summit
>>    planning :) ]
>>
>> I have just received a v1 to v11 patchset submission within roughly one
>> day timeframe.
>>
>> Neither myself nor anyone else did comment with any review feedback,
>> except for Sashiko. Which I believe is what triggered all the immediate
>> resubmissions.
>>
>> I don't think this is sustanable.
> 
> I think it might be fine to drop usual expectation of one patchset per
> 24h as long as maintainers can completely ignore patchsets with Sashiko
> replies.
> 
> If people want to keep bouncing the ball between them and Sashiko, they
> should be allowed and then we should be allowed just to silence that
> email thread completely.
> 
>>
>> The idea of throttling Sashiko's responses was gently nibbled at the
>> summit, and might be one of the options how to deal with this.
>>
>> Another option I'd like to propose would be to introduce a way for
>> submitters to run patches through back-and-forth with Sashiko even before
>> properly submitting the Sashiko-polished v1 to maintainers and
>> mailinglists.
> 
> I assume you mean they will be running it through Sashiko
> infrastructure, so using sponsored tokens. Otherwise that possibility is
> already there - you can run Sashiko, just a matter of money.

When a submitter uses LLMs to generate a patch, it is reasonable for
maintainers and reviewers to ask them to use shashiko to find problems
before sending it to us. Asking for a shashkiko run before submitting
patches could become part of the patch submitting process.

How about updating the submitting patches document to add a section on
this with instructions on how to run it?

This shifts the responsibility to run shashiko to people using LLMs.

thanks,
-- Shuah

Re: Patch pre-submission to Sashiko

[Arnaldo Melo]

On October 19, 2026 2:53:27 PM GMT-03:00, Shuah Khan <skhan@linuxfoundation.org> wrote:
>On 10/19/26 00:25, Krzysztof Kozlowski wrote:
>> On 17/10/2026 19:28, Jiri Kosina wrote:
>>> 
>>> [ in the spirit of the concluding discussion at this year's maintainers
>>>    summit,  I'm using this list outside of actual maintainer summit
>>>    planning :) ]
>>> 
>>> I have just received a v1 to v11 patchset submission within roughly one
>>> day timeframe.
>>> 
>>> Neither myself nor anyone else did comment with any review feedback,
>>> except for Sashiko. Which I believe is what triggered all the immediate
>>> resubmissions.
>>> 
>>> I don't think this is sustanable.
>> 
>> I think it might be fine to drop usual expectation of one patchset per
>> 24h as long as maintainers can completely ignore patchsets with Sashiko
>> replies.
>> 
>> If people want to keep bouncing the ball between them and Sashiko, they
>> should be allowed and then we should be allowed just to silence that
>> email thread completely.
>> 
>>> 
>>> The idea of throttling Sashiko's responses was gently nibbled at the
>>> summit, and might be one of the options how to deal with this.
>>> 
>>> Another option I'd like to propose would be to introduce a way for
>>> submitters to run patches through back-and-forth with Sashiko even before
>>> properly submitting the Sashiko-polished v1 to maintainers and
>>> mailinglists.
>> 
>> I assume you mean they will be running it through Sashiko
>> infrastructure, so using sponsored tokens. Otherwise that possibility is
>> already there - you can run Sashiko, just a matter of money.
>
>When a submitter uses LLMs to generate a patch, it is reasonable for
>maintainers and reviewers to ask them to use shashiko to find problems
>before sending it to us. Asking for a shashkiko run before submitting
>patches could become part of the patch submitting process.

I did run Sashiko locally in the past and even contributed patches for it, but it can be really expensive.

I need to try it again, but plain using /kseries with review-prompts on opencode with free LLMs, while this option is available, as it is now, in a local loop using a local model or a free cloud one, as I'm doing, would greatly reduce the public loop with sashiko.dev.

Right now: in OpenCode V2, no need for even an account:

/models

Select model

  Search
 
  MiniMax M3.1 Flash Free            Free
  Nemotron 3.5 Super VL Free       Free
  Beam Free                                       Free
  LongCat 2.5 Preview Free            Free
  MiMo-V2.6-Flash Free                  Free
  DeepSeek V4.1 Flash Free             Free
  GLM-5.3-Flash Free                        Free
  Nemotron 3.5 Lightning Free       Free
  Nemotron 3 Ultra Free                   Free
  Big Pickle                                         Free

Cheers,

- Arnaldo

>How about updating the submitting patches document to add a section on
>this with instructions on how to run it?
>
>This shifts the responsibility to run shashiko to people using LLMs.
>
>thanks,
>-- Shuah
>
>

- Arnaldo

Re: Patch pre-submission to Sashiko

[Theodore Tso]

On Mon, Oct 19, 2026 at 11:53:27AM -0500, Shuah Khan wrote:
> 
> When a submitter uses LLMs to generate a patch, it is reasonable for
> maintainers and reviewers to ask them to use shashiko to find problems
> before sending it to us. Asking for a shashkiko run before submitting
> patches could become part of the patch submitting process.
> 
> How about updating the submitting patches document to add a section on
> this with instructions on how to run it?
> 
> This shifts the responsibility to run shashiko to people using LLMs.

If people are using LLM's to generate a patch, it would be useful if
we can make it super easy for LLM's to call out to Sashiko as an
sub-agent.  We would probably want to make it easier for LLM's to run
our kunit and selftests as well.  Basically, we want to push the work
to the submmiter, instead of expecting the maintainer and/or reviewers
to do that work --- especially since if it's in the agenting coding
loop, the LLM agent can fix the problem more quickly and without
burning human review time.

					- Ted

Re: Patch pre-submission to Sashiko

[Chen-Yu Tsai]

On Tue, Oct 20, 2026 at 4:36 AM Theodore Tso <tytso@mit.edu> wrote:
>
> On Mon, Oct 19, 2026 at 11:53:27AM -0500, Shuah Khan wrote:
> >
> > When a submitter uses LLMs to generate a patch, it is reasonable for
> > maintainers and reviewers to ask them to use shashiko to find problems
> > before sending it to us. Asking for a shashkiko run before submitting
> > patches could become part of the patch submitting process.
> >
> > How about updating the submitting patches document to add a section on
> > this with instructions on how to run it?
> >
> > This shifts the responsibility to run shashiko to people using LLMs.
>
> If people are using LLM's to generate a patch, it would be useful if
> we can make it super easy for LLM's to call out to Sashiko as an
> sub-agent.  We would probably want to make it easier for LLM's to run
> our kunit and selftests as well.  Basically, we want to push the work
> to the submmiter, instead of expecting the maintainer and/or reviewers
> to do that work --- especially since if it's in the agenting coding
> loop, the LLM agent can fix the problem more quickly and without
> burning human review time.

AFAIK this is already possible as Roman mentioned in his presentation
at LPC.

And if Sashiko is too heavy or slightly harder to integrate, it is also
possible to just load the review prompts. Roman did point out to me in
private that this is not equivalent to running Sashiko though. This is
what I'm currently using at work.


ChenYu

Re: Patch pre-submission to Sashiko

[Jiri Kosina]

On Mon, 19 Oct 2026, Theodore Tso wrote:

> > When a submitter uses LLMs to generate a patch, it is reasonable for
> > maintainers and reviewers to ask them to use shashiko to find problems
> > before sending it to us. Asking for a shashkiko run before submitting
> > patches could become part of the patch submitting process.
> > 
> > How about updating the submitting patches document to add a section on
> > this with instructions on how to run it?
> > 
> > This shifts the responsibility to run shashiko to people using LLMs.
> 
> If people are using LLM's to generate a patch, it would be useful if
> we can make it super easy for LLM's to call out to Sashiko as an
> sub-agent.  

Yeah, but that pretty much brings us back to the potentially problematic 
"free tokens for anybody developing out-of-tree / proprietary kernel code" 
territory again.

-- 
Jiri Kosina
SUSE Labs

Re: Patch pre-submission to Sashiko

[Vlastimil Babka (SUSE)]

On 10/20/26 10:36, Jiri Kosina wrote:
> On Mon, 19 Oct 2026, Theodore Tso wrote:
> 
>> > When a submitter uses LLMs to generate a patch, it is reasonable for
>> > maintainers and reviewers to ask them to use shashiko to find problems
>> > before sending it to us. Asking for a shashkiko run before submitting
>> > patches could become part of the patch submitting process.
>> > 
>> > How about updating the submitting patches document to add a section on
>> > this with instructions on how to run it?
>> > 
>> > This shifts the responsibility to run shashiko to people using LLMs.
>> 
>> If people are using LLM's to generate a patch, it would be useful if
>> we can make it super easy for LLM's to call out to Sashiko as an
>> sub-agent.  
> 
> Yeah, but that pretty much brings us back to the potentially problematic 
> "free tokens for anybody developing out-of-tree / proprietary kernel code" 
> territory again.

I assumed Ted meant to call out to a local sashiko (as Roman explained,
using the LLM itself), not the hosted one?