From: Stefano Brivio <sbrivio@redhat.com>
To: Florian Westphal <fw@strlen.de>
Cc: etkaar <lists.netfilter.org@prvy.eu>,
netfilter@vger.kernel.org,
netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: Re: nftables >= 0.9.8: atomic update (nft -f ...) of a set not possible any more
Date: Wed, 5 Jan 2022 00:22:22 +0100 [thread overview]
Message-ID: <20220105002222.6695b8f7@elisabeth> (raw)
In-Reply-To: <20220104195728.GB938@breakpoint.cc>
Hi Florian,
On Tue, 4 Jan 2022 20:57:28 +0100
Florian Westphal <fw@strlen.de> wrote:
> etkaar <lists.netfilter.org@prvy.eu> wrote:
>
> [ CC Stefano ]
>
> > Dear colleagues,
> >
> > given is following perfectly working ruleset (nft list ruleset), which drops almost all of the IPv4 traffic, but grants access to port 22 (SSH) for two IPv4 addresses provided by the set named 'whitelist_ipv4_tcp':
>
> Thanks for reporting, I can reproduce this.
>
> > +++
> > table inet filter {
> > set whitelist_ipv4_tcp {
> > type inet_service . ipv4_addr
> > flags interval
> > elements = { 22 . 111.222.333.444,
> > 22 . 555.666.777.888 }
> > }
>
> I can repro this, looks like missing scratchpad cloning in the set
> backend.
>
> I can see that after second 'nft -f', avx2_lookup takes the 'if (unlikely(!scratch)) {' branch.
>
> Can you try this (kernel) patch below?
>
> As a workaround, you could try removing the 'interval' flag so that
> kernel uses a hash table as set backend instead.
>
> Stefano, does that patch make sense to you?
> Thanks!
Thanks for checking and fixing this!
Yes, it makes sense, a clone without a subsequent new insertion
wouldn't have a scratchpad otherwise -- I wonder how I missed this.
Just perhaps:
> diff --git a/net/netfilter/nft_set_pipapo.c b/net/netfilter/nft_set_pipapo.c
> --- a/net/netfilter/nft_set_pipapo.c
> +++ b/net/netfilter/nft_set_pipapo.c
> @@ -1271,7 +1271,7 @@ static struct nft_pipapo_match *pipapo_clone(struct nft_pipapo_match *old)
> {
> struct nft_pipapo_field *dst, *src;
> struct nft_pipapo_match *new;
> - int i;
> + int i, err;
>
> new = kmalloc(sizeof(*new) + sizeof(*dst) * old->field_count,
> GFP_KERNEL);
> @@ -1291,6 +1291,14 @@ static struct nft_pipapo_match *pipapo_clone(struct nft_pipapo_match *old)
> goto out_scratch;
> #endif
>
> + err = pipapo_realloc_scratch(new, old->bsize_max);
> + if (err) {
> +#ifdef NFT_PIPAPO_ALIGN
> + free_percpu(new->scratch_aligned);
> +#endif
I would use another label for this, "out_scratch_aligned", for
consistency with the rest of the error handling, but it's not a strong
preference.
> + goto out_scratch;
> + }
> +
> rcu_head_init(&new->rcu);
>
> src = old->f;
>
--
Stefano
prev parent reply other threads:[~2022-01-04 23:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5tg3b13w5.PCaY2G@prvy.eu>
2022-01-04 19:57 ` nftables >= 0.9.8: atomic update (nft -f ...) of a set not possible any more Florian Westphal
2022-01-04 23:22 ` Stefano Brivio [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=20220105002222.6695b8f7@elisabeth \
--to=sbrivio@redhat.com \
--cc=fw@strlen.de \
--cc=lists.netfilter.org@prvy.eu \
--cc=netfilter-devel@vger.kernel.org \
--cc=netfilter@vger.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;
as well as URLs for NNTP newsgroup(s).