From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamal Hadi Salim Subject: Re: broken behaviour of TC filter delete Date: Sun, 26 Aug 2018 13:48:17 -0400 Message-ID: References: <851sao225x.fsf@mojatatu.com> <20180824081751.GA2931@nanopsycho> <85sh33zqkh.fsf@mojatatu.com> <20180825130243.GE2931@nanopsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Mashak , Linux Kernel Network Developers , Jiri Pirko To: Jiri Pirko , Cong Wang Return-path: Received: from mail-io0-f172.google.com ([209.85.223.172]:44667 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726714AbeHZVbm (ORCPT ); Sun, 26 Aug 2018 17:31:42 -0400 Received: by mail-io0-f172.google.com with SMTP id 75-v6so11005517iou.11 for ; Sun, 26 Aug 2018 10:48:29 -0700 (PDT) In-Reply-To: <20180825130243.GE2931@nanopsycho> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 2018-08-25 9:02 a.m., Jiri Pirko wrote: > Fri, Aug 24, 2018 at 08:11:07PM CEST, xiyou.wangcong@gmail.com wrote: > >>> 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? > ENOENT with extack describing whether chain or filter not found. cheers, jamal