Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3840896pxb; Wed, 13 Oct 2021 14:12:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwS4OZbRZgJX4Txy2x2kXhg3z+KxSI+Rdnj6E/5nS4kxuqz2P7XCPRdSCiAMmwwVds7a4Cx X-Received: by 2002:a17:902:8f90:b0:13e:a44e:2d3c with SMTP id z16-20020a1709028f9000b0013ea44e2d3cmr1393063plo.85.1634159555710; Wed, 13 Oct 2021 14:12:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634159555; cv=none; d=google.com; s=arc-20160816; b=cBXXdqPFTPAx6LAiRMttbgAVlHP8zC/BPVeKMeBJMcdjM2msEEYB0Qrc/H2gu+sWnw qNhPuBOXUnfvUA8YQycZgDuBChxqmzZV/H+YKZMfceJx1nz6o3DEk3VzSWghwYjl7lxt 4NKP4q6vA89ahKnwnCBqjemb6TCGAg6XRnoErbJsAnkcAg3SM8ngrGwGgylZwn6Kxo3s pil/0GR7ZkUvktRFAvGF6YPBJUDf5/EynpJrnM7ZNj/SDEbTwTDFeM8tHs8L6ucQ4gIX QDnNjabx+lo14pf5i2hI0szUgcCHpYGTwFHxpUUBdxuZM+0K3g27Nq7sI4WV62a84KcJ u8yA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=fqdVMqF/bl5CWuyW+HsFhEpoYqKIDCP1H5eZGwCzFQA=; b=CD+VAQtvOkmtRpt00Uhui2Dc+qanDMw9n+Awonhj1IYRQd2I/2+Hr7wVkFXldMvNGS UbPcm8WY06fpe0a4uzKSq7rtNXmee/qPc2WcRyXcJaEmt7EGbxC0N2LSSZRvILT1G/US Q9c0lLIyo23YcI/TQJLfKGJmqoU9qGRAXcy4CiTVDIB5coiMTi4GkHXcifEBIqKlfxAW 5BsOt4YzwWTqQZSZ+V4xjzGB6Nhv8zEKX2QxsOsorZ8HMF/cFU8EdKTIe9mMqJ0+5LR4 5OrEpTcZPZiXk8Hf5byTKqt7HYSAPcwd9wA8OvhfzjaEZJJ5NT9JhnSLhVyQyonLBkmB G2zg== 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 p1si906597plq.398.2021.10.13.14.11.59; Wed, 13 Oct 2021 14:12:35 -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 S230016AbhJMVM0 (ORCPT + 99 others); Wed, 13 Oct 2021 17:12:26 -0400 Received: from mx3.molgen.mpg.de ([141.14.17.11]:60753 "EHLO mx1.molgen.mpg.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229882AbhJMVMZ (ORCPT ); Wed, 13 Oct 2021 17:12:25 -0400 Received: from localhost.localdomain (ip5f5ae911.dynamic.kabel-deutschland.de [95.90.233.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id 2425261E64760; Wed, 13 Oct 2021 23:10:20 +0200 (CEST) From: Paul Menzel To: Jamal Hadi Salim , Cong Wang , Jiri Pirko , "David S. Miller" , Jakub Kicinski Cc: Serhiy Boiko , Paul Menzel , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] net: sched: fix infinite loop when trying to create tcf rule Date: Wed, 13 Oct 2021 23:09:59 +0200 Message-Id: <20211013211000.8962-1-pmenzel@molgen.mpg.de> X-Mailer: git-send-email 2.33.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Serhiy Boiko After running a specific set of commands tc will become unresponsive: $ ip link add dev DEV type veth $ tc qdisc add dev DEV clsact $ tc chain add dev DEV chain 0 ingress $ tc filter del dev DEV ingress $ tc filter add dev DEV ingress flower action pass When executing chain flush the chain->flushing field is set to true, which prevents insertion of new classifier instances. It is unset in one place under two conditions: `refcnt - chain->action_refcnt == 0` and `!by_act`. Ignoring the by_act and action_refcnt arguments the `flushing procedure` will be over when refcnt is 0. But if the chain is explicitly created (e.g. `tc chain add .. chain 0 ..`) refcnt is set to 1 without any classifier instances. Thus the condition is never met and the chain->flushing field is never cleared. And because the default chain is `flushing` new classifiers cannot be added. tc_new_tfilter is stuck in a loop trying to find a chain where chain->flushing is false. Moving `chain->flushing = false` from __tcf_chain_put to the end of tcf_chain_flush will avoid the condition and the field will always be reset after the flush procedure. Signed-off-by: Serhiy Boiko [Upstreamed from https://github.com/dentproject/dentOS/commit/3480aceaa5244a11edfe1fda90afd92b0199ef23] Signed-off-by: Paul Menzel --- net/sched/cls_api.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c index 2ef8f5a6205a..405f955bef1e 100644 --- a/net/sched/cls_api.c +++ b/net/sched/cls_api.c @@ -563,8 +563,6 @@ static void __tcf_chain_put(struct tcf_chain *chain, bool by_act, if (refcnt - chain->action_refcnt == 0 && !by_act) { tc_chain_notify_delete(tmplt_ops, tmplt_priv, chain->index, block, NULL, 0, 0, false); - /* Last reference to chain, no need to lock. */ - chain->flushing = false; } if (refcnt == 0) @@ -615,6 +613,9 @@ static void tcf_chain_flush(struct tcf_chain *chain, bool rtnl_held) tcf_proto_put(tp, rtnl_held, NULL); tp = tp_next; } + + /* Last reference to chain, no need to lock. */ + chain->flushing = false; } static int tcf_block_setup(struct tcf_block *block, -- 2.33.0