On Sat, Aug 25, 2018 at 6:06 AM Jiri Pirko <j...@resnulli.us> wrote: > > Fri, Aug 24, 2018 at 08:11:07PM CEST, xiyou.wangc...@gmail.com wrote: > >On Fri, Aug 24, 2018 at 9:21 AM Roman Mashak <m...@mojatatu.com> 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?
Yeah, I think -ENOENT makes more sense than EINVAL here too.
