From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: Re: [nf-next 0/2] netfilter: nf_tables: make set flush more resistant to memory pressure
Date: Tue, 29 Jul 2025 13:37:19 +0200 [thread overview]
Message-ID: <aIiyVnDlbDTMRqB-@strlen.de> (raw)
In-Reply-To: <aIikwxU686KFto35@calendula>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> DELSETELEM does not unlink elements from set in the preparation phase,
> instead elements are marked as inactive in the next generation but
> they still remain linked to the set. These elements are removed from
> the set from either the commit/abort phase.
>
> - flush should skip elements that are already inactive
> - flush should not work on deleted sets.
> - flush command (elements are marked as inactive) then delete set
> skips those elements that are inactive. So abort path can unwind
> accordingly using the transaction id marker what I am proposing.
Yes, that part works, but we still need to kfree the elements after unlink.
When commit phase does the unlink, the element becomes unreachable from
the set. At this time, the DELSETELEM object keeps a pointer to the
unlinked elements, and that allows us to kfree after synchronize_rcu
from the worker. If we don't want DELSETELEM for flush, we need to
provide the address to free by other means, e.g. stick a pointer into
struct nft_set_ext.
next prev parent reply other threads:[~2025-07-29 11:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-04 12:30 [nf-next 0/2] netfilter: nf_tables: make set flush more resistant to memory pressure Florian Westphal
2025-07-04 12:30 ` [nf-next 1/2] netfilter: nf_tables: allow iter callbacks to sleep Florian Westphal
2025-07-04 12:30 ` [nf-next 2/2] netfilter: nf_tables: all transaction allocations can now sleep Florian Westphal
2025-07-24 23:19 ` [nf-next 0/2] netfilter: nf_tables: make set flush more resistant to memory pressure Pablo Neira Ayuso
2025-07-25 0:24 ` Florian Westphal
2025-07-25 10:10 ` Pablo Neira Ayuso
2025-07-25 11:15 ` Florian Westphal
2025-07-25 15:03 ` Pablo Neira Ayuso
2025-07-28 21:28 ` Florian Westphal
2025-07-29 7:22 ` Jozsef Kadlecsik
2025-07-29 10:27 ` Pablo Neira Ayuso
2025-07-29 10:50 ` Jozsef Kadlecsik
2025-07-29 10:38 ` Pablo Neira Ayuso
2025-07-29 11:37 ` Florian Westphal [this message]
2025-07-30 16:16 ` Pablo Neira Ayuso
2025-07-30 16:35 ` Florian Westphal
2025-08-19 19:10 ` Florian Westphal
2025-08-19 22:23 ` Pablo Neira Ayuso
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=aIiyVnDlbDTMRqB-@strlen.de \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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 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.