From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: broken behaviour of TC filter delete Date: Sat, 25 Aug 2018 15:02:43 +0200 Message-ID: <20180825130243.GE2931@nanopsycho> References: <851sao225x.fsf@mojatatu.com> <20180824081751.GA2931@nanopsycho> <85sh33zqkh.fsf@mojatatu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Roman Mashak , Linux Kernel Network Developers , Jiri Pirko , Jamal Hadi Salim To: Cong Wang Return-path: Received: from mail-wr1-f65.google.com ([209.85.221.65]:46403 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726412AbeHYQpN (ORCPT ); Sat, 25 Aug 2018 12:45:13 -0400 Received: by mail-wr1-f65.google.com with SMTP id a108-v6so9617958wrc.13 for ; Sat, 25 Aug 2018 06:06:17 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Fri, Aug 24, 2018 at 08:11:07PM CEST, xiyou.wangcong@gmail.com wrote: >On Fri, Aug 24, 2018 at 9:21 AM Roman Mashak wrote: >> >> 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. > >Yeah, at least we should keep ENOENT for compatibility. > >The bug here is chain 0 is gone after the last filter is gone, >so when you delete the filter again, it treats it as you specify >chain 0 which does not exist, so it hits EINVAL before ENOENT. I understand. My concern is about consistency with other chains. Perhaps -ENOENT for all chains in this case would be doable. What do you think? > >I am not sure how to fix this properly.