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: <20170418205525.7d8d18a1@cakuba.lan>
Date:   Tue, 18 Apr 2017 20:55:25 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Jamal Hadi Salim <jhs@...atatu.com>
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 Tue, 18 Apr 2017 21:37:12 -0400, Jamal Hadi Salim wrote:
> 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).

I see.

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

I'm just referring to the theoretical possibility that if the dumping
process gets preempted for long enough you may loose samples.  Just
because the dumping process cannot control when kernel executes this
line:

	jiffy_wanted = jiffies - jiffy_msecs;

It could in theory be few seconds after the request was made.  Perhaps
using timestamps from a proper time sources instead of the notion of
"last X seconds" would solve that?