From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by sourceware.org (Postfix) with ESMTPS id 3C100385782F for ; Thu, 20 May 2021 18:46:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3C100385782F Received: by mail-qt1-x830.google.com with SMTP id i19so7033805qtw.9 for ; Thu, 20 May 2021 11:46:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ASoZyNMV1xCVnugVfkHEGA+3IXuhpmNLCI//2Xr7bZ8=; b=HsGJYvDpvHLuZRIOzfCBRIiJ9wAqAU/ZJb9uMJHo2bUwsY9hFDmJMBWchMViXRx9YJ A/j0WSQd1TLh7kGwbaZfzjaSZjI+B9J+HnVwfa2HcRBOwAU/62LZzNBjzQ1L9+6h3Z/7 6094StOQNnVSwLO/WQzQ24pwOe+ghHmDDrQwcCTEVJomHTGwgfKcLiisecxR2tjPvVtc TTryrgaEg4peOm0lBmyOEyZD4Bs64SHQjWBiZ99g1qATtOWCSVQ0tKzSkyv+73lGdcsL mlc7xSYx3VHpsO75BLvLSSk2OxL1R6qhojdX2MnBV+cy0IiP3emKb2Jdl21QkcfZwLtS +6Xw== X-Gm-Message-State: AOAM530eno+CtkGDekWiRqjLUoF3mLoER+rIjzxEXUjH9/FlU8Frogji 0Arb8drAz9qLflitt6N3JBrKu8x+nDdngw== X-Google-Smtp-Source: ABdhPJy2HqGojUPwyX+pNlkR/kfsgcRT4oq+1IjfdKkkYhvaGG+AVybAz3qSXXJr5x/UUrWqveVg0Q== X-Received: by 2002:a05:622a:446:: with SMTP id o6mr7036358qtx.246.1621536400598; Thu, 20 May 2021 11:46:40 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id t13sm848663qtn.63.2021.05.20.11.46.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 May 2021 11:46:40 -0700 (PDT) Subject: Re: [PATCH v2 06/25] linux: Add fallback for 64-bit time_t SO_TIMESTAMP{NS} To: Florian Weimer , Adhemerval Zanella via Libc-alpha References: <20210518205613.1487824-1-adhemerval.zanella@linaro.org> <20210518205613.1487824-7-adhemerval.zanella@linaro.org> <87v97dsxub.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: <4937dcf7-574a-097d-c809-5d95fdde1e24@linaro.org> Date: Thu, 20 May 2021 15:46:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87v97dsxub.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 18:46:42 -0000 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.