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

[Pablo Neira Ayuso <pablo@netfilter.org>]

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.

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

In that regard, my impression is that LLMs are a bit overwhelming
because they complain about one aspect that still needs to be
addressed. Not coming in this series, but I can see this is happening
too with Florian when he has been addressing some of the existing
issues with ipset hashtable resizing.

Oh well, and me, because most of the reports here seem to be like
pre-existing issues.

Just my two cents here, these folks are doing very useful work and
they (and me too) will just follow up on pre-existing issues.