On Fri, Aug 23, 2019 at 5:48 PM Ido Schimmel <[email protected]> wrote:
>
> From: Ido Schimmel <[email protected]>
>
> Timestamps are currently communicated to user space as 'struct
> timespec', which is not considered y2038 safe since it uses a 32-bit
> signed value for seconds.
>
> Fix this while the API is still not part of any official kernel release
> by using 64-bit nanoseconds timestamps instead.
>
> Fixes: ca30707dee2b ("drop_monitor: Add packet alert mode")
> Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for
> hardware drops")
> Signed-off-by: Ido Schimmel <[email protected]>
> ---
> Arnd, I have followed your recommendation to use 64-bit nanoseconds
> timestamps. I would appreciate it if you could review this change.
somewhat late reply:
> @@ -761,8 +759,8 @@ static int net_dm_hw_packet_report_fill(struct sk_buff
> *msg,
> goto nla_put_failure;
> }
>
> - if (ktime_to_timespec_cond(skb->tstamp, &ts) &&
> - nla_put(msg, NET_DM_ATTR_TIMESTAMP, sizeof(ts), &ts))
> + if (nla_put_u64_64bit(msg, NET_DM_ATTR_TIMESTAMP,
> + ktime_to_ns(skb->tstamp), NET_DM_ATTR_PAD))
> goto nla_put_failure;
>
> if (nla_put_u32(msg, NET_DM_ATTR_ORIG_LEN, skb->len))
Yes, this looks reasonable. I guess since we take the skb timestamps
in CLOCK_REALTIME, there is little point in trying to use
CLOCK_MONOTONIC in the user interface.
64-bit nanoseconds are safe for a few hundred years.
Arnd
