Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp355661rwi; Wed, 2 Nov 2022 12:45:13 -0700 (PDT) X-Google-Smtp-Source: AMsMyM75lk4xAFgngcak6GVIM3qTxMg1R4NoeIaUt7ErHx5KemQemMP/fO38OLTYEj+w/UQOLa6i X-Received: by 2002:a63:cf0d:0:b0:46e:96b9:2760 with SMTP id j13-20020a63cf0d000000b0046e96b92760mr22924916pgg.328.1667418313297; Wed, 02 Nov 2022 12:45:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667418313; cv=none; d=google.com; s=arc-20160816; b=S7ISmrBEDNXuwR2RFWV7hLCaF1eot+K5pAvBtdJo/AVbLCiZFw8lDnPtjlV79UusVt qlRtFdO/gc/4xh7kk9SxoIBTj2j4IGPSa6aYrkMmnFZrPIZP/AnGTMkAW177Lp4aO1/s LwbmKG05vPWVyKd+42Mj5O0pcHbypPVSybBYBk6L2BGvn5Ou69fXW+61zADh5aLmBc9u Tnz2SxMLpr6jwtRuNrP1TQGepbi6V5QLI/ejryBF0K7eMDNf36IFjxxos9E6D9TkWucK r2bKDnCmCYcwl+jMV9znc7JKI+Kc/Ncy/0dWj6rSTSo+fKmTgfNGhagEbo5EF/2vPt59 5XXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=uHo3hHZUQ81I8SibsoClN7pdNhsW1x+x1w8Dn9aFWCw=; b=UCqpP5H7/bxIKHhlhY1AqtKbyUdLjo3Y2j1XB6TCpVmeFBmP4pg7n94lq6JJFqlQew tWpBq0pRn0PD4bZwiMFjNYJvGJbd+jhC8WzbfPh6FDhG/OFjCjb1f281G8/8aiJBNgyA 4mr5AV9kcg903l8FGC5sUtw42nQZIiaLz/yAWdxVjA8npp+2k+rIASULILh7dgIaW7HX goBvUD7QJAqhKayW3fR79xXCjuebvQAV2kCnFF3L5dwtPWKDCmmxEKDy+6SJ8YYZp16t szulJ5f5WuX/1whlsm48OGEWY/O6DWB/oYTNLRnw8ZAtTLSZ4IskdHc7yI5BqMoOfzTL Tdxg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f2-20020a63de02000000b0043aebb63fc9si16609182pgg.732.2022.11.02.12.45.00; Wed, 02 Nov 2022 12:45:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231668AbiKBSwX (ORCPT + 98 others); Wed, 2 Nov 2022 14:52:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231336AbiKBSwV (ORCPT ); Wed, 2 Nov 2022 14:52:21 -0400 Received: from mail.netfilter.org (mail.netfilter.org [217.70.188.207]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9B196CEF; Wed, 2 Nov 2022 11:52:20 -0700 (PDT) Date: Wed, 2 Nov 2022 19:52:14 +0100 From: Pablo Neira Ayuso To: Michael Lilja Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jonathan Corbet , Jozsef Kadlecsik , Florian Westphal , netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org Subject: Re: [PATCH] Periodically flow expire from flow offload tables Message-ID: References: <20221023171658.69761-1-michael.lilja@gmail.com> <381FF5B6-4FEF-45E9-92D6-6FE927A5CC2D@gmail.com> <25246B91-B5BE-43CA-9D98-67950F17F0A1@gmail.com> <03E5D5FA-5A0D-4E5A-BA32-3FE51764C02E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <03E5D5FA-5A0D-4E5A-BA32-3FE51764C02E@gmail.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 26, 2022 at 09:40:11PM +0200, Michael Lilja wrote: > Hi, > > I just quickly tried following the flow_offload_teardown() path instead of clearing IPS_OFFLOAD in flow_offload_del() and it does have some side effects. The flow is added again before the HW has actually reported it to be NF_FLOW_HW_DEAD. > > The sequence with my patch is: > : Retire -> Remove from hw tables -> Remove from sw tables -> kfree(flow) -> flow_offload_add() > > But if flow_offload_teardown() is called on expire I see: > : Retire -> Remove from hw tables -> flow_offload_add() -> Remove from sw tables -> kfree(flow) > > I need to investigate why this happens, maybe the IPS_OFFLOAD flag is cleared too early and should not be cleared until the flow is actually removed, like I do? Maybe the issue is not seen before because on timeout or flow_is_dying() no packet arrive to create the flow again prematurely? Hm, IPS_OFFLOAD should be cleared from flow_offload_del() then, it is cleared too early. I'll post a fix for nf.git first then I propose to follow up on this flowtable feature. I'll keep you on Cc.