Re: [PATCH net 00/11] Netfilter/IPVS fixes for net

[Julian Anastasov <ja@ssi.bg>]

	Hello,

On Tue, 29 Sep 2026, Pablo Neira Ayuso wrote:

> Hi Jakub, Paolo,
> 
> On Mon, Sep 28, 2026 at 07:11:20PM -0700, Jakub Kicinski wrote:
> > On Mon, 28 Sep 2026 00:08:05 +0200 Pablo Neira Ayuso wrote:
> > > The following batch contains Netfilter fixes for net:
> > 
> > I didn't spot anything obviously needing a respin in the AI feedback,
> > could you confirm that it's good as is? If you have to respin it'd be
> > good to remove the claim that patch 2 is a nop, Linus is onto us for
> > sending too many LLM-induced, low impact fixes.
> 
> I would say yes too. LLM comments say:
> 
> - Patch 2/11 (ipvs): commit description could be improved (yes, there
>   is always room for improvement in that regard but I think description
>   is fair fine enough). There is a report on a pre-existing issue, but
>   I think that can be addressed as a follow up.

	I already have v2 for 2/11, now as 2 patches:

https://sashiko.dev/#/patchset/20260929113436.44306-1-ja%40ssi.bg

	But better to leave it for next week, it is a low
priority fix. As usually, if we stop 1 patch, it is replaced
by 2 for the next round :)

> - Patch 3/11 (netfilter): commit description could be improved again,
>   but patch is good IMO.
> 
> - Patch 7/11 (ipvs): there's seem to be another path to abuse this
>   code LLM found, I would address this as a follow up.
> 
> - Patch 8/11 (netfilter): refers to a pre-existing issue.
>   It also refers to issues with reordering elements of the range,
>   but this API really need elements in order to work fine, otherwise
>   overlap detection will likely fire.
> 
> - Patch 10/11 (netfilter): refers to a pre-existing issues.
>   nf_flow_offload_refresh() also needs to be disabled in pending
>   work is enqueued. Also disable stats fetching for dying hw entries.
> 
> In particular, I am observing IPVS patches are getting stuck because
> of reports of pre-existing issues. Sometimes you find two or three
> things that need an adjustment, and you can start tackling one of the
> aspects at a time (because addressing them all at once it not easy).
> I think it will help Julian if he has a chance to address issues as
> follow up, unless LLM reports something really sound and compelling
> that can be classified as a blocker.

	I don't find the LLM reviews wrong, so I don't
complain :) I'll note if a followup is preferred but in
most of the time the patches need to be corrected. I try
to post different patches for the different problems but
this is also a load for the other maintainers. I hope
I'll improve with the time but it is true that we are
overloaded. The only hope is that the bug-report rate will
slowdown with the time...

Regards

--
Julian Anastasov <ja@ssi.bg>