From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Mashak Subject: broken behaviour of TC filter delete Date: Thu, 23 Aug 2018 17:39:22 -0400 Message-ID: <851sao225x.fsf@mojatatu.com> Mime-Version: 1.0 Content-Type: text/plain Cc: jiri@mellanox.com, Jamal Hadi Salim To: netdev@vger.kernel.org Return-path: Received: from mail-it0-f54.google.com ([209.85.214.54]:53491 "EHLO mail-it0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727485AbeHXBLA (ORCPT ); Thu, 23 Aug 2018 21:11:00 -0400 Received: by mail-it0-f54.google.com with SMTP id k188-v6so4980067itk.3 for ; Thu, 23 Aug 2018 14:39:23 -0700 (PDT) Sender: netdev-owner@vger.kernel.org List-ID: It appears that the following commit changed the behaviour of scenario where a filter is deleted twice: commit f71e0ca4db187af7c44987e9d21e9042c3046070 Author: Jiri Pirko Date: Mon Jul 23 09:23:05 2018 +0200 net: sched: Avoid implicit chain 0 creation Steps to reproduce : 1) create dummy device $ ip link add dev dummy0 type dummy 2) create qdisc $ tc qdisc add dev dummy0 ingress 3) create simple u32 filter with action attached $ tc filter add dev dummy0 parent ffff: protocol ip prio 1 u32 match ip src 10.10.10.1/32 action ok 4) list the filter $ tc filter ls dev dummy0 parent ffff: 5) delete the filter with the given protocol and priority $ tc filter del dev dummy0 parent ffff: protocol ip prio 1 6) repeat step 5, this will return -ENOENT ("Error: Filter with specified priority/protocol not found.") However, before the change at step 6 we would get -EINVAL (Error: Cannot find specified filter chain.) and that makes sense. The change breaks a number of our internal TC tests.