lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 11 Aug 2016 17:08:30 -0700
From:	Cong Wang <xiyou.wangcong@...il.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [Patch net 0/5] net_sched: tc action fixes and updates

On Thu, Aug 11, 2016 at 9:20 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
> On 16-08-10 04:06 PM, Cong Wang wrote:
>>
>> On Wed, Aug 10, 2016 at 7:34 AM, Jamal Hadi Salim <jhs@...atatu.com>
>> wrote:
>>>
>>> On 16-08-08 04:46 PM, Cong Wang wrote:
>
>
>>> tcf_exts_exec() is the culprit - and conversion to from flexarray
>>> to linked list in the fast problem to be specific.
>>
>>
>> Ah, this reminds me that I don't have to use flex_array, initially
>> I thought the tcf_exts could hold as many actions as it wants,
>> but actually there is a upper bound, TCA_ACT_MAX_PRIO.
>> IOW, a regular dynamic array is just enough here.
>>
>
> Yes, a regular array would be enough.
>
>
>> I just replaced the flex_array with a regular one, it works fine
>> for me too, at least no crash with all of my test cases.
>>
>
> Ok, I did a quick look at your patch - I still see you converting
> from array to list. I mean get tcf_exts_exec() to take an array
> and walk it. That will restore the perf numbers to the same level.


Makes sense! I just did this change as you suggest.


>
>> Please try v2, since you have more test cases that I do.
>> Or it would be great if you can share your test cases with
>> me or us.
>>
>> Be patient, every big change could have regression. :)
>>
>
> No problem Cong - except we have a kernel that crashes right now.
> BTW: I just thought of another test which uses a different code
> path
> # add a policer rule
> sudo $TC actions add action police rate 1kbit burst 90k drop
> #dump rules..
> sudo $TC -s actions ls action police
>

Passed:

[root@...alhost ~]# tc actions add action police rate 1kbit burst 90k drop
[root@...alhost ~]# tc actions ls action police

action order 0:  police 0x1 rate 1000bit burst 23440b mtu 2Kb action
drop overhead 0b
ref 1 bind 0
[root@...alhost ~]# tc -s actions ls action police

action order 0:  police 0x1 rate 1000bit burst 23440b mtu 2Kb action
drop overhead 0b
ref 1 bind 0
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0


Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ