netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: xiaolinkui <xiaolinkui@126.com>
Cc: pablo@netfilter.org, kadlec@netfilter.org, fw@strlen.de,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, justinstitt@google.com, kuniyu@amazon.com,
	netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Linkui Xiao <xiaolinkui@kylinos.cn>
Subject: Re: [PATCH] netfilter: ipset: wait for xt_recseq on all cpus
Date: Thu, 5 Oct 2023 14:31:07 +0200	[thread overview]
Message-ID: <20231005123107.GB9350@breakpoint.cc> (raw)
In-Reply-To: <20231005115022.12902-1-xiaolinkui@126.com>

xiaolinkui <xiaolinkui@126.com> wrote:
> From: Linkui Xiao <xiaolinkui@kylinos.cn>
> 
> Before destroying the ipset, take a check on sequence to ensure that the
> ip_set_test operation of this ipset has been completed.
> 
> The code of set_match_v4 is protected by addend=xt_write_recseq_begin() and
> xt_write_recseq_end(addend). So we can ensure that the test operation is
> completed by reading seqcount.

Nope, please don't do this, the xt_set can also be used from nft_compat
which doesn't use the xtables packet traversers.

I'd rather use synchonize_rcu() once in ip_set_destroy(), that will
make sure all concurrent traversers are gone.

That said, I still do not understand this fix, the
match / target destroy hooks are called after the table has
been completely replaced, i.e., while packets can still be in flight
no packets should be within the ipset lookup functions when
this happens, and no more packets should be able to enter them.

AFAICS the request to delete the set will fail if its still referenced
via any rule. xt_set holds references to the sets.

So:
1. set have dropped all references
2. userspace *can* delete the set
3. we get crash because xt_set was still within a sets eval
  function.

I don't see how 3) can happen, xt table replace isn't supposed
to call the xt_set destroy functions until after table replace.

We even release the entire x_table blob right afterwards.

  reply	other threads:[~2023-10-05 16:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05 11:50 [PATCH] netfilter: ipset: wait for xt_recseq on all cpus xiaolinkui
2023-10-05 12:31 ` Florian Westphal [this message]
2023-10-05 14:50   ` Jozsef Kadlecsik
2023-10-16  8:51 ` kernel test robot
2023-10-16 12:56   ` Jozsef Kadlecsik
2023-10-16  9:14 ` kernel test robot

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=20231005123107.GB9350@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=justinstitt@google.com \
    --cc=kadlec@netfilter.org \
    --cc=kuba@kernel.org \
    --cc=kuniyu@amazon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    --cc=xiaolinkui@126.com \
    --cc=xiaolinkui@kylinos.cn \
    /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).