From: Ilya Maximets <i.maximets@ovn.org>
To: Ilya Maximets <i.maximets@ovn.org>, netfilter-devel@vger.kernel.org
Cc: netdev@vger.kernel.org, "Donald Hunter" <donald.hunter@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Pablo Neira Ayuso" <pablo@netfilter.org>,
"Florian Westphal" <fw@strlen.de>, "Phil Sutter" <phil@nwl.cc>,
"Shuah Khan" <shuah@kernel.org>,
"Asbjørn Sloth Tønnesen" <ast@fiberby.net>,
"Matthieu Baerts (NGI0)" <matttbe@kernel.org>,
"Remy D. Farley" <one-d-wide@protonmail.com>,
linux-kernel@vger.kernel.org, coreteam@netfilter.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH nf-next] netfilter: conntrack: make filtering by zone discoverable
Date: Mon, 7 Sep 2026 11:57:31 +0200 [thread overview]
Message-ID: <0956bec0-163f-480d-ad31-5e547fbe0bab@ovn.org> (raw)
In-Reply-To: <20260904174452.1913072-1-i.maximets@ovn.org>
On 9/4/26 7:44 PM, Ilya Maximets wrote:
> Conntrack flush supports filtering by zone using CTA_ZONE, but this
> attribute is really hard to use from user space applications. The
> reason is that it is not possible to tell if it's supported or not.
>
> Older kernels silently ignore CTA_ZONE. And in that case they just
> happily flush all the entries from all zones breaking all the existing
> connections. So, applications have to infer support from the kernel
> version. While it works in most cases, it's not a particularly
> reliable or desired way to check kernel capabilities from applications
> that aim to be portable. There should be a better way to probe or
> discover features in the kernel.
>
> The CTA_FILTER interface on the other hand is simple enough to probe.
> We can check for NLM_F_DUMP_FILTERED in the dump to see if filtering
> is supported. And unknown sub-attributes in CTA_FILTER are rejected
> explicitly since strict validation is in use there.
>
> Let's add new CTA_FILTER_ZONE that signals that CTA_ZONE should be
> filtered on. It is a flag, since everything in the CTA_FILTER is a
> bit mask, i.e., a form of a flag. If set, it means that CTA_ZONE must
> be present and be used for filtering. If the flag is not set however,
> the filtering on CTA_ZONE will still take place to ensure backwards
> compatibility. So, the flag doesn't really change the filtering
> behavior, but it allows user space applications to properly discover
> support for CTA_ZONE filtering without need to rely on kernel version
> parsing or risk accidental flushes of the entire conntrack table,
> and also without modifying the kernel state.
>
> A new test variant is added to test with and without the new flag.
> Since the setup code is moved into a shared function, expectations
> replaced with assertions to bail early if the base setup fails to
> avoid the cascade of secondary failures that can be misleading.
> Error return is only for the SKIP cases.
>
> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
> ---
>
> One other alternative is to make CTA_FILTER_ZONE a U16 sub-attribute
> instead of a FLAG and prioritize it over the CTA_ZONE. But it feels
> like a FLAG is better suited for the CTA_FILTER, even if it takes a
> bit of extra space in the request. Though I'm OK with reworking this
> into U16 or some other mechanism that would make the feature
> discoverable, if there are better ideas.
>
> Documentation/netlink/specs/conntrack.yaml | 5 +
> .../linux/netfilter/nfnetlink_conntrack.h | 1 +
> net/netfilter/nf_conntrack_netlink.c | 11 ++
> .../net/netfilter/conntrack_dump_flush.c | 143 ++++++++++++------
> 4 files changed, 115 insertions(+), 45 deletions(-)
[...]
> -FIXTURE_SETUP(conntrack_dump_flush)
> +static int conntrack_zone_setup(struct __test_metadata *_metadata,
> + struct mnl_socket **sock)
> {
> struct in6_addr src, dst;
> int ret;
>
> - self->sock = mnl_socket_open(NETLINK_NETFILTER);
> - if (!self->sock) {
> + *sock = mnl_socket_open(NETLINK_NETFILTER);
> + if (!*sock) {
> perror("mnl_socket_open");
> - SKIP(return, "cannot open netlink_netfilter socket");
> + SKIP(return -1, "cannot open netlink_netfilter socket");
> }
>
> - ret = mnl_socket_bind(self->sock, 0, MNL_SOCKET_AUTOPID);
> + ret = mnl_socket_bind(*sock, 0, MNL_SOCKET_AUTOPID);
> EXPECT_EQ(ret, 0);
Sashiko-gemini (sashiko-nipa didn't run, probably because the patch was
moved to changes-requested due to the CI issue) pointed out that I missed
converting this expectation into an assert. I can do that in v2 once
the CI is working again.
Best regards, Ilya Maximets.
prev parent reply other threads:[~2026-09-07 9:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 17:44 [PATCH nf-next] netfilter: conntrack: make filtering by zone discoverable Ilya Maximets
2026-09-04 18:06 ` Ilya Maximets
2026-09-04 18:13 ` Matthieu Baerts
2026-09-07 9:57 ` Ilya Maximets [this message]
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=0956bec0-163f-480d-ad31-5e547fbe0bab@ovn.org \
--to=i.maximets@ovn.org \
--cc=ast@fiberby.net \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=matttbe@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=one-d-wide@protonmail.com \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
--cc=shuah@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox