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:
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
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
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
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
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:
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
