From: Florian Westphal <fw@strlen.de>
To: Fernando Fernandez Mancera <fmancera@suse.de>
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
phil@nwl.cc, pablo@netfilter.org,
Alejandro Olivan Alvarez <alejandro.olivan.alvarez@gmail.com>
Subject: Re: [PATCH nf] netfilter: nf_conncount: prevent connlimit drops for early confirmed ct
Date: Wed, 13 May 2026 16:13:35 +0200 [thread overview]
Message-ID: <agSHD2ZVclEeKSJC@strlen.de> (raw)
In-Reply-To: <7fbd428e-93b7-4e17-8360-5434f0d1f6bc@suse.de>
Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> About IP_CT_ESTABLISHED, I added it because it was not clear to me that
> IPS_ASSURED_BIT is always set. I guess yes for TCP/UDP but what about
> other protocols? (Are we supporting other protocols???) Anyway, I have
> tested it and confirmed that for TCP/UDP it is safe to drop it.
SCTP is the only other relevant one for this use-case, I think.
> And please note that the idea is to be cautious when returning --EXIST.
> If IPS_ASSURED_BIT is set we can for sure skip the tracking BUT if not,
> we run a GC skipping the skip optimization..
6 months from now I will no longer know wtf this assured check is
doing. Please consider rewriting the existing comments so that this
makes some sense.
> Is it that bad? I mean, it has some back and forth and I apologize for
> that but overall this is fixing some real use cases.
I know, this isn't your fault. Conncount is used in all kinds of cases
that it wasn't designed for and thus we have this esoteric breakage in
first place.
No way we can avoid it. I think your patch is the best we can do here.
next prev parent reply other threads:[~2026-05-13 14:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 12:15 [PATCH nf] netfilter: nf_conncount: prevent connlimit drops for early confirmed ct Fernando Fernandez Mancera
2026-05-13 12:45 ` Florian Westphal
2026-05-13 13:48 ` Fernando Fernandez Mancera
2026-05-13 14:13 ` Florian Westphal [this message]
2026-05-13 14:52 ` Fernando Fernandez Mancera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agSHD2ZVclEeKSJC@strlen.de \
--to=fw@strlen.de \
--cc=alejandro.olivan.alvarez@gmail.com \
--cc=coreteam@netfilter.org \
--cc=fmancera@suse.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.