Re: Some clarifications on the upstreaming process

[Matthieu Baerts <matttbe@kernel.org>]

Hi Steffen, Paolo,

(+cc Pablo, Florian)

Sorry to jump in the discussion, but I have similar issues with MPTCP
patches.

On 09/09/2026 11:23, Paolo Abeni wrote:
> On 9/9/26 8:38 AM, Steffen Klassert wrote:

(...)

>> 4) Some patches for the ipsec and ipsec-next tree don't get Sashiko
>> reviews either because they don't apply to net or net-next, or
>> because of some other reasons I'm not aware of.

From what I saw, sashiko.dev tries to apply patches on top of the
correct tree by at least looking at the modified files and the
MAINTAINERS file, and possibly the prefix [1] from what I understood.

For example this recent patch [2] got applied on top of 96f01b53c2d0,
which corresponds to today's 'ipset' tree [3] (tag: ipsec-2026-09-07)

[1] https://github.com/sashiko-dev/sashiko/issues/48
[2]
https://sashiko.dev/#/patchset/migrate-state-fixes-v2-0-c3e2767f0d96%40secunet.com
[3] https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git

For Clashiko, it only tests what's for net/net-next, same as for the
selftests, etc. if I'm not mistaken.

>> This is the biggest
>> issue, I see the Sashiko review only after I sent a pull request.
>> This makes the upstreaming process complicated and delays fixes
>> quite a bit. I requested some infrastructure from the LF to get
>> this fixed, but no answer so far. Any other ideas how to fix
>> this issue?
> 
> I think are 2 separate points:
> 
> 4.1 missing sashiko reviews on edge cases
> 4.2 difficulty to reproduce the sashiko/clashiko review process in advance.
> 
> WRT 4.1 things should generally improve over time, with the exception of
> patch that do not apply. I think we can't do much for them, but they
> also should not matter much, right?
> 
> WRT 4.2 the current guidance is to run AI reviews before submission.
> Sashiko could be installed and run locally. The nipa instance (clashiko)
> is slighly more effective than sashiko.dev because it runs several
> recent models and its result are indeed hard to replicate locally/in
> advance.
> 
> Clashiko currently runs on (very significant) meta-sponsored budget, I
> think it would be hard to extend it's usage to netdev's subsystems.

We might need to find a solution for the subsystems for this 4th point.
I have the same issue with MPTCP, and it seems it is the same with
Netfilter (and likely others) from what I saw. I would prefer to have
Clashiko reviews before applying patches on my side: to reduce the risk
to deal with new issues later on, and to let the author dealing with
that (instead of me days/weeks after).

From what I understood, Clashiko is still being tweaked, and that's the
current priority. Maybe later, subsystems can have their patches
reviewed by Clashiko as well?

If that's a budget issue that cannot be solved easily, I wonder if
Clashiko shouldn't ignore subsystems patches: I see its value, but I
also see the cost for the different subsystems :-/

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.