netdev - Re: [PATCH net-next 1/1] net sched actions: add time filter for action dumping

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]

Message-ID: <930f107b-ac5f-3fab-445b-9050437c1909@mojatatu.com>
Date:   Tue, 18 Apr 2017 21:37:12 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Jakub Kicinski <kubakici@...pl>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        xiyou.wangcong@...il.com, eric.dumazet@...il.com, jiri@...nulli.us
Subject: Re: [PATCH net-next 1/1] net sched actions: add time filter for
 action dumping

On 17-04-18 06:12 PM, Jakub Kicinski wrote:

> Noob question - would it be an option to establish some form of
> streaming statistic updates out of the kernel?

It would be more efficient, certainly. Current polling approach is not
as bad though (you send one extra kernel message) and is more reliable
(events generated by the kernel are not reliably delivered to user
space).

> The notion of user
> space trying to keep track of the time here seems a bit shaky.

You mean the patch i sent or suggestion you are making would be
more shaky?
I see both being fine from that perspective - you dont need 100%
accuracy. Just something that is within reason of a small delta
of time.

>Would
> it be an option with netlink to open a socket and request specific
> set of statistic to be dumped on it periodically if they changed?
> I guess it would be way more code that the patch you present...

Sensible but like you said more code.
For efficiency you will need to have some tweakables.
Possibly something that could specify "send me X events or whatever
youve accumulated in Y seconds" etc.

Note: Here we open one socket;
and every X seconds we ask the kernel to give us whatever changed
in the last X seconds or so.

There are some drawbacks. If it takes you longer than X seconds to
walk over everything then you are in trouble. The earlier patch
speeds us up a bit. And I have some other rough patches I am
where we could have multiple threads asking for both time and
specific index ranges to make sure we got everything in time.
For a couple of million actions, I havent found big need for
those yet;->

cheers,
jamal