Re: [PATCH net 00/13] Netfilter/IPVS fixes for net
Pablo Neira Ayuso <[email protected]>
| Newsgroups | gmane.linux.network,gmane.comp.security.firewalls.netfilter.devel |
|---|---|
| Message-ID | <anugqXmnyKSMPl_w@chamomile> |
On Tue, Aug 11, 2026 at 10:23:33PM +0200, Florian Westphal wrote: > Jakub Kicinski <[email protected]> wrote: > > On Mon, 10 Aug 2026 21:06:08 +0200 Pablo Neira Ayuso wrote: > > > The following patchset contains Netfilter/IPVS fixes for net. Still > > > large batch for this late -rc cycle but at least have of these fixes in > > > this batch have been cooking for several weeks before: > > > > Does any of the AI-detected issues seem concerning? > > > > https://netdev-ai.bots.linux.dev/sashiko/#/patchset/[email protected] > > Only commenting on those patches that I worked on or commented during > review: > > Patch 6: [PATCH net 06/13] netfilter: nf_conntrack: defer invalid log until after unlock > > Its fine. This is for debugging. We could restore the removed info if > anyone needs it, I even was about to suggest to original author to > simply remove the invalid logging but decided against it (since you can > log the packet to userspace via nfnetlink). I prefer the simpler > version that doesn't snapshot data while under lock. > > Patch 7: [PATCH net 07/13] netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state > > Yes, one could have added this Fixes tag or Cc stable to the patch. > Don't think this warrants a respin by itself. > > Patch 12: [PATCH net 12/13] netfilter: ipset: fix list type element drift bug > > Even if the ordering is "wrong", the patch that > added it is ancient (even in RHEL7) so its long established behaviour. > > ipset test suite also has test for this and those tests pass, so > changing kernel behaviour will need to adjust (old..) test cases as > well. Patch 10: [PATCH net 10/13] netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path This is known issue and I've been working on a patch to address what sashiko reports, basically, in case hardware offload is enabled, errors should also rollback to the previous state. There seem to be a path with hardware offload indirect flow block that is buggy because ENOMEM is propagated as EOPNOTSUPP. I need to follow up. Patch 11: [PATCH net 11/13] netfilter: flowtable: publish GC-visible tuple last Sashiko indicates that this needs a follow up because hardware offload can still trigger a race with GC. This also needs a follow up.