Re: [PATCH v3 0/8] net: y2038-safe socket timestamps
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: 2019-01-08 13:37:49
Also in:
linux-alpha, linux-arch, linux-rdma, linux-s390, lkml, sparclinux
On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani [off-list ref] wrote:
The series introduces new socket timestamps that are
y2038 safe.
The time data types used for the existing socket timestamp
options: SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING
are not y2038 safe. The series introduces SO_TIMESTAMP_NEW,
SO_TIMESTAMPNS_NEW and SO_TIMESTAMPING_NEW to replace these.
These new timestamps can be used on all architectures.
The alternative considered was to extend the sys_setsockopt()
by using the flags. We did not receive any strong opinions about
either of the approaches. Hence, this was chosen, as glibc folks
preferred this.
The series does not deal with updating the internal kernel socket
calls like rxrpc to make them y2038 safe. This will be dealt
with separately.
Note that the timestamps behavior already does not match the
man page specific behavior:
SIOCGSTAMP
This ioctl should only be used if the socket option SO_TIMESTAMP
is not set on the socket. Otherwise, it returns the timestamp of
the last packet that was received while SO_TIMESTAMP was not set,
or it fails if no such packet has been received,
(i.e., ioctl(2) returns -1 with errno set to ENOENT).
The recommendation is to update the man page to remove the above statement.
The overview of the series is as below:
1. Delete asm specific socket.h when possible.
2. Support SO/SCM_TIMESTAMP* options only in userspace.
3. Rename current SO/SCM_TIMESTAMP* to SO/SCM_TIMESTAMP*_OLD.
3. Alter socket options so that SOCK_RCVTSTAMPNS does
not rely on SOCK_RCVTSTAMP.
4. Introduce y2038 safe types for socket timestamp.
5. Introduce new y2038 safe socket options SO/SCM_TIMESTAMP*_NEW.
Changes since v2:
* Removed extra functions to reduce diff churn as per code reviewThanks, Deepa. This set looks great to me. One issue, it does not apply cleanly to current davem-net-next/master for me. A conflict on patch 7. It does apply cleanly on davem-net master. Please rebase and also send with [PATCH net-next]. Perhaps also run the selftests in tools/testing/selftests/networking/timestamping/txtimestamp.sh, just to be sure. Since you have a to resend anyway, a few minor nits inline, as well.