On Tue, Jul 4, 2023, at 21:36, Willem de Bruijn wrote:
On Mon, 2023-07-03 at 14:25 -0700, John Fastabend wrote:
Jörn-Thorben Hinz wrote:
Yes, if there is no objection to making the added getsockopt(SO_TIMESTAMPING_NEW) this tiny bit more “strict”, it’s just a matter of modifying the if inserted in sk_getsockopt(). (And, well, in the other case I would even remove this if.)
The difference is in the struct that is returned, on 32-bit platforms. Both calls should always be allowed? See also put_cmsg_scm_timestamping64 vs put_cmsg_scm_timestamping.
For the second patch: the _OLD/_NEW was introduced to work around limitations on 32-bit platforms. This is intended to be transparent to users, by defining SO_TIMESTAMPING accordingly.
Can the new BPF code always enforce the 64-bit version, that is, only implement the _NEW variants? And perhaps just call it SO_TIMESTAMPING directly.
I guess that depends on how the returned timestamps are interpreted.
In normal userspace code, the 'struct scm_timestamping' is defined in terms of the libc-provided 'struct timespec'. If this is a normal glibc based distro binary, then it probably expects the old format.
OTOH, if the code reading the timestamp data is in BPF code itself, it's probably safe to mandate that to use the time64 format and define the timespec type as __kernel_timespec with 64-bit members.
Arnd