Re: broken behaviour of TC filter delete

2018-08-27 Thread Cong Wang
On Sat, Aug 25, 2018 at 6:06 AM Jiri Pirko 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 wrote: > >> > >> So _before_ commit f71e0ca4db187af7c44987e9d21e9042c3046070 step 6 would > >> return -ENOENT with "Error: Fi

Re: broken behaviour of TC filter delete

2018-08-26 Thread Jamal Hadi Salim
On 2018-08-25 9:02 a.m., Jiri Pirko wrote: Fri, Aug 24, 2018 at 08:11:07PM CEST, xiyou.wangc...@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

Re: broken behaviour of TC filter delete

2018-08-25 Thread Jiri Pirko
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 wrote: >> >> So _before_ commit f71e0ca4db187af7c44987e9d21e9042c3046070 step 6 would >> return -ENOENT with "Error: Filter with specified priority/protocol not >> found." and _after

Re: broken behaviour of TC filter delete

2018-08-24 Thread Cong Wang
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 chai

Re: broken behaviour of TC filter delete

2018-08-24 Thread Roman Mashak
Jiri Pirko writes: > Thu, Aug 23, 2018 at 11:39:22PM CEST, m...@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:

Re: broken behaviour of TC filter delete

2018-08-24 Thread Jiri Pirko
Thu, Aug 23, 2018 at 11:39:22PM CEST, m...@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: sc

broken behaviour of TC filter delete

2018-08-23 Thread Roman Mashak
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 d