From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Mashak Subject: Re: broken behaviour of TC filter delete Date: Fri, 24 Aug 2018 12:18:06 -0400 Message-ID: <85sh33zqkh.fsf@mojatatu.com> References: <851sao225x.fsf@mojatatu.com> <20180824081751.GA2931@nanopsycho> Mime-Version: 1.0 Content-Type: text/plain Cc: netdev@vger.kernel.org, jiri@mellanox.com, Jamal Hadi Salim To: Jiri Pirko Return-path: Received: from mail-io0-f179.google.com ([209.85.223.179]:39149 "EHLO mail-io0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726268AbeHXTx2 (ORCPT ); Fri, 24 Aug 2018 15:53:28 -0400 Received: by mail-io0-f179.google.com with SMTP id l7-v6so7573732iok.6 for ; Fri, 24 Aug 2018 09:18:08 -0700 (PDT) In-Reply-To: <20180824081751.GA2931@nanopsycho> (Jiri Pirko's message of "Fri, 24 Aug 2018 10:17:51 +0200") Sender: netdev-owner@vger.kernel.org List-ID: Jiri Pirko writes: > Thu, Aug 23, 2018 at 11:39:22PM CEST, mrv@mojatatu.com wrote: >> >> >>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. > > Wait, this now returns: > Error: Cannot find specified filter chain. > So you want it to return -EINVAL (Error: Cannot find specified filter chain.) ? > How about for other chains? > I must've mixed up the return codes and messages while typing the message. So _before_ commit f71e0ca4db187af7c44987e9d21e9042c3046070 step 6 would return -ENOENT with "Error: Filter with specified priority/protocol not found." and _after_ the commit it returns -EINVAL (Error: Cannot find specified filter chain.) ENOENT seems to be more logical to return when there's no more filter to delete.