Re: [PATCH net-next 01/11] netfilter: synproxy: fix reset of ct seqadj when reopening a connection

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

Hi,

Just a gentle bump to this net-next PR containing Netfilter updates.

Let me know if there is anything that needs to be addressed.

Thanks.

On Mon, Sep 28, 2026 at 01:04:07AM +0200, Pablo Neira Ayuso wrote:
> Hi,
> 
> On Sun, Sep 27, 2026 at 10:40:44PM +0000, netdev-bot+sinfo@kernel.org wrote:
> > Hi!
> > 
> > This is an automated message. This series looks like a fix, but its
> > commit messages seem to be missing some information:
> > 
> >  - How the issue was discovered, e.g. hit in production, hit during
> >    development, syzbot report, manual code inspection, LLM or static
> >    analysis tool scan.
> > 
> >  - Whether the issue was actually triggered, or is only theoretical
> >    (e.g. found by code inspection). If it was triggered please include
> >    the symptoms, like the stack trace or error messages.
> >
> > Please do not repost the series just to address the above. Instead,
> > reply to this email with the missing information, so that reviewers
> > can take it into account. If the series needs another revision for
> > other reasons, please include the information in the commit messages
> > then.
> >
> > The evaluation is done by an LLM so it may be wrong, if you think
> > that is the case please reply and explain.
> 
> This are correctness fixes (no crashes to my knowledged, hence I
> decided to target net-next) as the cover letter specifies:
> 
> Patch #1 TCP sequence tracking issue was reported by sashiko as the
>          cover letter says.
> 
> Patch #2 Just documentation update to fix incorrect information
>          about the maximum number of expectations.
> 
> Patch #3 Just a cleanup patch to remove a break;
> 
> Patch #4 Just a cleanup, typos in comments.
> 
> Patch #5 and #6 are the result of a human triggered review of the
>          conntrack error stats by Phil Sutter, I think.
> 
> Patch #7 is a preparation patch for #8.
> 
> Patch #8 removes a unnecessary workqueue flush, submitter does not
>          specify if it is visible in production, I suspect with
>          a very large number of netns it must be. Author does not
>          claim LLM assistance.
> 
> Patch #9 is a fix triggered by sashiko report IIRC, I deemed it too
>          large for net so I am routing this rework-fix to net-next.
> 
> Patch #10 is a feature fix, IPv6 filtering does not work.
>           I suspect it was found when trying to use this (broken)
>           feature by the submitter.
> 
> Patch #11 Ilya Maximets reports the CTA_ZONE filtering feature is
>           not easy to infer from userspace, I don't think LLM
>           triggered this, it looks more like an improvement to help
>           userspace tools discover this feature.
> 
> This is human written reply, my cover letter has been generated by me
> too to provide more context on these patches.
> 
> Thanks!
>