netdev - Re: [PATCH RFC net-next] netlink: Add support for timestamping messages

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: <bc050de1-a6fb-9669-e3c7-0901dfedd8d6@gmail.com>
Date:   Mon, 13 May 2019 20:51:54 -0600
From:   David Ahern <dsahern@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH RFC net-next] netlink: Add support for timestamping
 messages

On 5/9/19 10:51 AM, David Miller wrote:
> From: David Ahern <dsahern@...nel.org>
> Date: Thu,  9 May 2019 08:55:42 -0700
> 
>> From: David Ahern <dsahern@...il.com>
>>
>> Add support for timestamping netlink messages. If a socket wants a
>> timestamp, it is added when the skb clone is queued to the socket.
>>
>> Allow userspace to know the actual time an event happened. In a
>> busy system there can be a long lag between when the event happened
>> and when the message is read from the socket. Further, this allows
>> separate netlink sockets for various RTNLGRP's where the timestamp
>> can be used to sort the messages if needed.
>>
>> Signed-off-by: David Ahern <dsahern@...il.com>
>> ---
>> one question I have is whether it would be better to add the timestamp
>> when the skb is created so it is the same for all sockets as opposed to
>> setting the time per socket.
> 
> If the importance is that the timestamp is when the "event" occurs
> then you should set it at skb creation time.
> 

The overhead of adding the timestamp is why I was thinking of setting it
based on a socket request.

If I defer setting the timestamp to do_one_broadcast only systems where
a process / socket wanting a timestamp takes the overhead and all
processes / sockets wanting the timestamp see the same the one. Seems
like a good trade-off. It is a very small time gap between the skb
allocation and do_one_broadcast.

Worst case scenario is a notification storm such as a huge route dump
into the kernel. Enabling the timestamp does have a measurable overhead
(~15% for a notification storm of ~240,000/sec). Given all of the other
improvements the end result is still a huge gain, but to defer the
overhead only to users who want it seems like the right thing to do.