Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp318778pxu; Wed, 14 Oct 2020 02:03:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy12voHBkTVjMyzD3M+KqDLPSfra8W+jG+w0x7SjDAKK8KNOiGS0Jv/d0zTIceTITK//kJT X-Received: by 2002:a17:907:33d2:: with SMTP id zk18mr4290023ejb.145.1602666233981; Wed, 14 Oct 2020 02:03:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602666233; cv=none; d=google.com; s=arc-20160816; b=sjlFxhXWHL6vkYlOGALPPluci9nnuCWRnC2hX0RJWY7ekksujk4FxLJT4XVnxF2UGV APB68aqOs9qDcDh59t+GN+MW2YIFjTNqAL4sYyI6jXQcTdDtRNPEBQ5/j5DpY080D1gZ 7j1sv7ui7r+ZUwQmINQQKZWyLvehYeGgxYKJAgU+LObsZCjA6ebCbLxVWD06z/XFMpOW 4G3lCVecaUHn8zjtO6wKZ3j3v3VOfG0LTSn4iP7NKlASZjw0eU8si+CUSBWuT7/B+Oxc nxeO+fZkRnPGeLnleTYOggClh7TCPcUe1dkybVGkpcjE1F1OfDVJpxxD5Kgc1IakzC2P ARTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=BACuhR1cBqQ2uIC0jxQwtewgsWnidN3DarU8/AOXpTY=; b=ggsIH4lKb2yHpNo6wNJ21co+kmKS/LGPN2pn1PXF5IHx5/RmGKbscje4Afw7oEw0Wc A8TDPrcrqW7lvCOmSevwdTpt1gqo4E8pEc2sCCM30Tdpm9dnWHs3YlH6urHBH6ZZM9+Z fwLmauJC57heXw8kT/ibBPJ8iuCzjOGkN+c5AA1CPXkkFqYk2iG3Ht6Qw27euGM4raaF agOeSIagcLGlmWLxMGM57D2Nur7YPSnTA7LA4J/LJ78IfhuIUmx8jojyL1JyU2FQUYa4 GgpXAFm07b3M0TkKcyun3idvIWKZWNH+KxfDdjGgEfxR6wLUiSWC4zifFd/jQJbtHp1c zULA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v15si1715234edj.221.2020.10.14.02.03.31; Wed, 14 Oct 2020 02:03:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728292AbgJNIXv (ORCPT + 99 others); Wed, 14 Oct 2020 04:23:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726320AbgJNIXt (ORCPT ); Wed, 14 Oct 2020 04:23:49 -0400 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:12e:520::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1A7BC051111; Wed, 14 Oct 2020 01:23:50 -0700 (PDT) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1kSc4T-0000RN-HK; Wed, 14 Oct 2020 10:23:41 +0200 Date: Wed, 14 Oct 2020 10:23:41 +0200 From: Florian Westphal To: Pablo Neira Ayuso Cc: Florian Westphal , Jozsef Kadlecsik , Francesco Ruggeri , open list , netdev , coreteam@netfilter.org, netfilter-devel@vger.kernel.org, Jakub Kicinski , David Miller Subject: Re: [PATCH nf v2] netfilter: conntrack: connection timeout after re-register Message-ID: <20201014082341.GA16895@breakpoint.cc> References: <20201007193252.7009D95C169C@us180.sjc.aristanetworks.com> <20201009110323.GC5723@breakpoint.cc> <20201009185552.GF5723@breakpoint.cc> <20201009200548.GG5723@breakpoint.cc> <20201014000628.GA15290@salvia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201014000628.GA15290@salvia> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pablo Neira Ayuso wrote: > > Yes, we iterate table on re-register and modify the existing entries. > > For iptables-nft, it might be possible to avoid this deregister + > register ct hooks in the same transaction: Maybe add something like > nf_ct_netns_get_all() to bump refcounters by one _iff_ they are > 0 > before starting the transaction processing, then call > nf_ct_netns_put_all() which decrements refcounters and unregister > hooks if they reach 0. No need, its already fine. Decrement happens from destroy path, so new rules are already in place. > The only problem with this approach is that this pulls in the > conntrack module, to solve that, struct nf_ct_hook in > net/netfilter/core.c could be used to store the reference to > ->netns_get_all and ->net_put_all. > > Legacy would still be flawed though. Its fine too, new rule blob gets handled (and match/target checkentry called) before old one is dismantled. We only have a 0 refcount + hook unregister when rules get flushed/removed explicitly.