Received: by 2002:a05:7412:518d:b0:e2:908c:2ebd with SMTP id fn13csp390686rdb; Thu, 5 Oct 2023 08:48:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFyrOVfw7Ez07b3Wk6o3Y+glhTBqkuae27YAPrCLJMGQJqy7zLJDdvXm4ngqzVXF0JkWSc7 X-Received: by 2002:a05:6e02:1786:b0:34f:7779:df7f with SMTP id y6-20020a056e02178600b0034f7779df7fmr7699494ilu.0.1696520931391; Thu, 05 Oct 2023 08:48:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696520931; cv=none; d=google.com; s=arc-20160816; b=g3UHeJFVBjmzPxspf6JSowjeK2G/EaZjdhMPCHjfARf3R2LzIh/oUq1RZamYBjb5U3 e+9Gc85WOgNCPj8zWE8vo1Jw0Lpnsn8ONWK8VAHuGDfurh5xtJSmbfU0XVOeqWOlxBXo ZJh2bkxIwqV+X57NscUOa0Xtg20nfX51SrgKVi07DhVGlhKSoO2BHII6vNIg4K2lGFtp brUWrnAdjTWJ94Tt575oDf5Pn41ZkTUe7EioZKePztpevBaDWIPCqUN6an0hmNUifuot 2nJLsyMSQpatTNY35Zu7A6n7S/a9EvNmFxFbfhAPVrCSCqQKDL9ci0mbM2jtmdt2Ym/R LKnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date; bh=CVHHNRVfLFAh/LIN09LXTGk5ngRlt/29DSIRgu6sy1c=; fh=ovxfuOIbLS1qk8HRVpcoOblQegqXGbQSqBkPCXBMvv8=; b=yMdXWWaxp3eSdacBGxUj/dEjJemlmClii9IlgYo5/TRpG4EsXz1KbMCyUHIhrRqsX0 hNkPbZ2JAAOk0rZYgFcFmDVu12o6BdS9mjXP0T/Oz4QTymm2yhO7446ifO0rGLjG8DN3 Mf1KehMMhBeIYjFOaZKtOa4fWkpEIFNCiKAcNyeaSGFmiE8Ec0rhqJTS2SSVNG65LfI2 efuBwKdkq2QW47D63E/CHB0Jr/JvBCy3FKFdl6HGLgokkWJMHi5W4aBGZCP1kSm8lQtR +pHI3EPaK1jUcZ8V+Gnxp8BcfaZ6waf+k39nFOL5lDqzWI7ESDFc2A+ZKve3UuacbLTh 6PkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id bv3-20020a632e03000000b0057745d87b50si1605760pgb.139.2023.10.05.08.48.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Oct 2023 08:48:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id E67108377240; Thu, 5 Oct 2023 08:48:30 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234328AbjJEPql (ORCPT + 99 others); Thu, 5 Oct 2023 11:46:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233929AbjJEPpR (ORCPT ); Thu, 5 Oct 2023 11:45:17 -0400 X-Greylist: delayed 585 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 05 Oct 2023 08:02:08 PDT Received: from smtp-out.kfki.hu (smtp-out.kfki.hu [148.6.0.48]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87EEA21D00; Thu, 5 Oct 2023 08:02:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp2.kfki.hu (Postfix) with ESMTP id 16261CC02C3; Thu, 5 Oct 2023 16:50:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at smtp2.kfki.hu Received: from smtp2.kfki.hu ([127.0.0.1]) by localhost (smtp2.kfki.hu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP; Thu, 5 Oct 2023 16:50:43 +0200 (CEST) Received: from blackhole.kfki.hu (blackhole.szhk.kfki.hu [148.6.240.2]) by smtp2.kfki.hu (Postfix) with ESMTP id 52ACACC02C0; Thu, 5 Oct 2023 16:50:42 +0200 (CEST) Received: by blackhole.kfki.hu (Postfix, from userid 1000) id 096853431A9; Thu, 5 Oct 2023 16:50:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by blackhole.kfki.hu (Postfix) with ESMTP id 076443431A8; Thu, 5 Oct 2023 16:50:42 +0200 (CEST) Date: Thu, 5 Oct 2023 16:50:42 +0200 (CEST) From: Jozsef Kadlecsik To: Florian Westphal cc: xiaolinkui , Pablo Neira Ayuso , David Miller , 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 Subject: Re: [PATCH] netfilter: ipset: wait for xt_recseq on all cpus In-Reply-To: <20231005123107.GB9350@breakpoint.cc> Message-ID: <2c9efd36-f1f6-b77b-d4eb-f65932cfaba@netfilter.org> References: <20231005115022.12902-1-xiaolinkui@126.com> <20231005123107.GB9350@breakpoint.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-0.7 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 05 Oct 2023 08:48:31 -0700 (PDT) On Thu, 5 Oct 2023, Florian Westphal wrote: > xiaolinkui wrote: > > From: Linkui Xiao > > > > 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. But ip_set_destroy() can be called only when there's no reference to the set in the kernel and thus there's no ipset function whatsoever in the packet path which would access it. > 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. I'd expect the author to send patches to netfilter-devel@vger.kernel.org first in order to review netfilter and ipset related patches there. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics H-1525 Budapest 114, POB. 49, Hungary