Re: Some clarifications on the upstreaming process

[Steffen Klassert <steffen.klassert@secunet.com>]

On Wed, Sep 09, 2026 at 11:23:56AM +0200, Paolo Abeni wrote:
> On 9/9/26 8:38 AM, Steffen Klassert wrote:
> > I need some clarifications on how to handle future ipsec patches.
> > Since we have the AI-generated patches and patch reviews things
> > changed quite a bit and I have problems to upstream ipsec fixes.
> > 
> > I have the following problematic situations:
> > 
> > 1) Sashiko found nothing in the original patch submisstion,
> > but found an issue when I resent the patch with the pull
> > request. I think this can be solved by asking the author
> > to send an incremental fix on top of the ipsec tree if
> > it does not happen too often.
> 
> This is usually the correct approach, with some exceptions i.e. the
> newly found issue is impactful (the new code is exploitable).

Are you willing to pull this as is, or should I resend the pull
request with the incremental fix? The latter leads to problem
4.1 (patch does not apply to net).

> 
> > 2) How to treat preexisting issues that are not introduced by the
> > patch under review? I'd say that's ok as long as the bug is
> > completely fixed with the patch. Is that acceptable?
> 
> Yes, pre-existing issue are generally better handled as follow-up. With
> some exception. i.e. sometimes sashiko says "this is a pre-existing
> issue, but it looks like the path doesn't actually fix the pre-existing
> issue it's supposed to fix..."o
> 
> Or when the pre-existing issue is very strongly tied to the issue at hand.
> > 3) Which severity is ok to accept? Maybe this:
> > 
> > - High, only if the review is wrong?
> > - Medium, only with good reson?
> > - Low, ok to accept?
> 
> AFAIK the above is the current general guidance.
> 
> Note that some brief comments on the ML in reply to sashiko feedback
> would help in all the above mentioned cases.

Ok, will do this.

> > 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. 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?

Well, the 'patch does not apply' is one of my biggest problems.

> WRT 4.2 the current guidance is to run AI reviews before submission.
> Sashiko could be installed and run locally.

If somebody pays for the LLM tokens...

I don't have any influence on the patch author. But as most of
the patches are AI-generated, I'd guess they have some AI review
too. Unfortunately this does not mean they are correct.

> 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.

But that would fix the issue. Finally all the patches are reviewd by
Clashiko anyway when I send the pull request. If the nipa picks the
correct tree (ipsec or ipsec-next) the patches get reviewed already
when submitted and I could send the pull request without attaching
the patches. So this would be still one review per patch.

The current workflow makes me running in circles. I have no idea
how many iterations it needs to get a PR upstream, while the
queue of new patches continues to grow.