From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org, sbrivio@redhat.com
Subject: Re: [PATCH nf-next v2 7/8] netfilter: nft_set_pipapo: move cloning of match info to insert/removal path
Date: Fri, 10 May 2024 02:40:08 +0200 [thread overview]
Message-ID: <Zj1s6HcwpUsHKkrK@calendula> (raw)
In-Reply-To: <20240425120651.16326-8-fw@strlen.de>
Hi Florian,
I have iterated several times over this batch, but I came up with one
late question today, see below.
On Thu, Apr 25, 2024 at 02:06:46PM +0200, Florian Westphal wrote:
> This set type keeps two copies of the sets' content,
> priv->match (live version, used to match from packet path)
> priv->clone (work-in-progress version of the 'future' priv->match).
>
> All additions and removals are done on priv->clone. When transaction
> completes, priv->clone becomes priv->match and a new clone is allocated
> for use by next transaction.
>
> Problem is that the cloning requires GFP_KERNEL allocations but we
> cannot fail at either commit or abort time.
>
> This patch defers the clone until we get an insertion or removal
> request. This allows us to handle OOM situations correctly.
>
> This also allows to remove ->dirty in a followup change:
>
> If ->clone exists, ->dirty is always true
> If ->clone is NULL, ->dirty is always false, no elements were added
> or removed (except catchall elements which are external to the specific
> set backend).
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
> ---
> net/netfilter/nft_set_pipapo.c | 73 ++++++++++++++++++++++++----------
> 1 file changed, 52 insertions(+), 21 deletions(-)
>
> diff --git a/net/netfilter/nft_set_pipapo.c b/net/netfilter/nft_set_pipapo.c
> index 9c8da9a0861d..2b1c91e56ca1 100644
> --- a/net/netfilter/nft_set_pipapo.c
> +++ b/net/netfilter/nft_set_pipapo.c
> @@ -615,6 +615,9 @@ nft_pipapo_get(const struct net *net, const struct nft_set *set,
> struct nft_pipapo_match *m = priv->clone;
> struct nft_pipapo_elem *e;
>
> + if (!m)
> + m = rcu_dereference(priv->match);
nft_pipapo_get() is called from rcu path via _GET netlink command.
Is it safe to walk over priv->clone? Userspace could be updating
(with mutex held) while a request to get an element can be done.
That makes me think nft_pipapo_get() should always use priv->match?
Thanks, and apologies for the late review.
next prev parent reply other threads:[~2024-05-10 0:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-25 12:06 [PATCH nf-next v2 0/8] nft_set_pipapo: remove cannot-fail allocations on commit and abort Florian Westphal
2024-04-25 12:06 ` [PATCH nf-next v2 1/8] netfilter: nft_set_pipapo: move prove_locking helper around Florian Westphal
2024-04-25 12:06 ` [PATCH nf-next v2 2/8] netfilter: nft_set_pipapo: make pipapo_clone helper return NULL Florian Westphal
2024-04-25 12:06 ` [PATCH nf-next v2 3/8] netfilter: nft_set_pipapo: prepare destroy function for on-demand clone Florian Westphal
2024-04-25 12:06 ` [PATCH nf-next v2 4/8] netfilter: nft_set_pipapo: prepare walk " Florian Westphal
2024-04-26 5:44 ` Stefano Brivio
2024-04-25 12:06 ` [PATCH nf-next v2 5/8] netfilter: nft_set_pipapo: merge deactivate helper into caller Florian Westphal
2024-04-25 12:06 ` [PATCH nf-next v2 6/8] netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone Florian Westphal
2024-04-25 12:06 ` [PATCH nf-next v2 7/8] netfilter: nft_set_pipapo: move cloning of match info to insert/removal path Florian Westphal
2024-05-10 0:40 ` Pablo Neira Ayuso [this message]
2024-05-10 8:29 ` Florian Westphal
2024-04-25 12:06 ` [PATCH nf-next v2 8/8] netfilter: nft_set_pipapo: remove dirty flag Florian Westphal
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=Zj1s6HcwpUsHKkrK@calendula \
--to=pablo@netfilter.org \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=sbrivio@redhat.com \
/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).