Re: [PATCH v2 06/25] linux: Add fallback for 64-bit time_t SO_TIMESTAMP{NS}

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 20/05/2021 03:50, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
> 
>> Calls with __TIMESIZE=32 will see the converted 64-bit time control
>> messages as spurious control message of unknown type.  Calls with
>> __TIMESIZE=64 running on pre-time64 kernels will see the original
>> message as a spurious control ones of unknown typ while running on
>> kernel with native 64-bit time support will only see the time64 version
>> of the control message.
> 
> Does the mirror what the kernel does?  I have some concerns about
> backwards compatibility here, but if the kernel does it as well, that is
> likely a non-issue.

The SO_TIMESTAMP{NS}_OLD to SO_TIMESTAMP{NS}_NEW for _TIME_BITS=64 is
what this patch does to add some compatibility. From kernel code:
net/socket.c

 772 void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
 773         struct sk_buff *skb)
 774 {
 775         int need_software_tstamp = sock_flag(sk, SOCK_RCVTSTAMP);
 776         int new_tstamp = sock_flag(sk, SOCK_TSTAMP_NEW);

[...]
 790         if (need_software_tstamp) {
 791                 if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
 792                         if (new_tstamp) {
 793                                 struct __kernel_sock_timeval tv;
 794 
 795                                 skb_get_new_timestamp(skb, &tv);
 796                                 put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP_NEW,
 797                                          sizeof(tv), &tv);
 798                         } else {
 799                                 struct __kernel_old_timeval tv;
 800 
 801                                 skb_get_timestamp(skb, &tv);
 802                                 put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP_OLD,
 803                                          sizeof(tv), &tv);
 804                         }
 805                 } else {
 806                         if (new_tstamp) {
 807                                 struct __kernel_timespec ts;
 808 
 809                                 skb_get_new_timestampns(skb, &ts);
 810                                 put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMPNS_NEW,
 811                                          sizeof(ts), &ts);
 812                         } else {
 813                                 struct __kernel_old_timespec ts;
 814 
 815                                 skb_get_timestampns(skb, &ts);
 816                                 put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMPNS_OLD,
 817                                          sizeof(ts), &ts);
 818                         }
 819                 }
 820         }

For _TIME_BITS=32, SO_TIMESTAMP{NS} will be exported as the 
SO_TIMESTAMP{NS}_OLD and if the process sets a SO_TIMESTAMPING{NS}_NEW 
somehow the control message will be unknown.

For _TIME_BITS=64, SO_TIMESTAMP will be exported as the SO_TIMESTAMP_NEW.
Programs that set SO_TIMESTAMP{NS}_OLD will be converted to 
SO_TIMESTAMP{NS}_NEW.  This translation is *not* done by the kernel,
but the conversion should be safe as long CMSG_SPACE is large enough (and
the __convert_scm_timestamps does check for it).

> 
> I think this kind of emulation goes against our general guidance of not
> emulating system calls in userspace.  It would probably be necessary if
> we switch an existing 32-bit target to 64-bit time_t by default, though.

I am not sure this characterize as emulation, but rather fall in what we
do for 64 time support. Otherwise newer code won't see SO_TIMESTAMP{NS}_OLD
values and I think it might be a more difficult breakage than getting
32-bit timestamp values.