From mboxrd@z Thu Jan 1 00:00:00 1970 From: Deepa Dinamani Subject: Re: [PATCH 7/8] socket: Add SO_TIMESTAMP[NS]_NEW Date: Sat, 24 Nov 2018 21:28:07 -0800 Message-ID: References: <20181124022035.17519-1-deepa.kernel@gmail.com> <20181124022035.17519-8-deepa.kernel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: y2038-bounces@lists.linaro.org Sender: "Y2038" To: willemdebruijn.kernel@gmail.com Cc: "open list:RALINK MIPS ARCHITECTURE" , Parisc List , Arnd Bergmann , y2038 Mailman List , Linux Network Devel Mailing List , Linux Kernel Mailing List , Ralf Baechle , "James E.J. Bottomley" , linux-rdma@vger.kernel.org, Alexander Viro , linux-alpha@vger.kernel.org, sparclinux , "David S. Miller" , rth@twiddle.net List-Id: linux-rdma@vger.kernel.org PiA+ID4gKyAgICAgICBpZiAodHlwZSA9PSBTT19USU1FU1RBTVBfTkVXIHx8IHR5cGUgPT0gU09f VElNRVNUQU1QTlNfTkVXKQo+ID4gPiArICAgICAgICAgICAgICAgc29ja19zZXRfZmxhZyhzaywg U09DS19UU1RBTVBfTkVXKTsKPiA+ID4gKyAgICAgICBlbHNlCj4gPiA+ICsgICAgICAgICAgICAg ICBzb2NrX3Jlc2V0X2ZsYWcoc2ssIFNPQ0tfVFNUQU1QX05FVyk7Cj4gPiA+ICsKPiA+Cj4gPiBp ZiBhZGRpbmcgYSBib29sZWFuIHdoZXRoZXIgdGhlIHNvY2tldCB1c2VzIG5ldyBvciBvbGQtc3R5 bGUKPiA+IHRpbWVzdGFtcHMsIHBlcmhhcHMgZmFpbCBoYXJkIGlmIGEgcHJvY2VzcyB0cmllcyB0 byBzZXQgYSBuZXctc3R5bGUKPiA+IG9wdGlvbiB3aGlsZSBhbiBvbGQtc3R5bGUgaXMgYWxyZWFk eSBzZXQgYW5kIHZpY2UgdmVyc2EuIEFsc28gaW5jbHVkZQo+ID4gU09fVElNRVNUQU1QSU5HX05F VyBhcyBpdCB0b2dnbGVzIHRoZSBzYW1lIG9wdGlvbi4KCkkgZG8gbm90IHRoaW5rIHRoaXMgaXMg YSBwcm9ibGVtLgpDb25zaWRlciB0aGlzIGV4YW1wbGUsIGlmIHRoZXJlIGlzIGEgdXNlciBhcHBs aWNhdGlvbiB3aXRoIHVwZGF0ZWQKc29ja2V0IHRpbWVzdGFtcHMgaXMgbGlua2luZyBpbnRvIGEg bGlicmFyeSB0aGF0IGlzIHlldCB0byBiZSB1cGRhdGVkLgoKQmVzaWRlcywgdGhlIG9sZCB0aW1l c3RhbXBzIHNob3VsZCB3b3JrIHBlcmZlY3RseSBmaW5lIG9uIDY0IGJpdAphcmNoZXMgZXZlbiBi ZXlvbmQgMjAzOC4KU28gZmFpbGluZyBoZXJlIG1lYW5zIGFkZGluZyBhIGJ1bmNoIG9mIGlmZGVm J3MgdG8gdmVyaWZ5IGl0IGlzIG5vdApleGVjdXRpbmcgb24gNjQgYml0IGFyY2ggb3Igc29tZXRo aW5nIGxpa2UgeDMyLgoKPiA+ID4gZGlmZiAtLWdpdCBhL25ldC9zb2NrZXQuYyBiL25ldC9zb2Nr ZXQuYwo+ID4gPiBpbmRleCBkM2RlZmJhNTU1NDcuLjlhYmViNmJjOWNmZSAxMDA2NDQKPiA+ID4g LS0tIGEvbmV0L3NvY2tldC5jCj4gPiA+ICsrKyBiL25ldC9zb2NrZXQuYwo+ID4gPiBAQCAtNjk5 LDYgKzY5OSwzOCBAQCBzdGF0aWMgdm9pZCBwdXRfdHNfcGt0aW5mbyhzdHJ1Y3QgbXNnaGRyICpt c2csIHN0cnVjdCBza19idWZmICpza2IpCj4gPiA+ICAgICAgICAgICAgICAgICAgc2l6ZW9mKHRz X3BrdGluZm8pLCAmdHNfcGt0aW5mbyk7Cj4gPiA+ICB9Cj4gPiA+Cj4gPiA+ICtzdGF0aWMgdm9p ZCBzb2NrX3JlY3Zfc3dfdGltZXN0YW1wKHN0cnVjdCBtc2doZHIgKm1zZywgc3RydWN0IHNvY2sg KnNrLAo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBza19i dWZmICpza2IpCj4gPiA+ICt7Cj4gPiA+ICsgICAgICAgaWYgKHNvY2tfZmxhZyhzaywgU09DS19U U1RBTVBfTkVXKSkgewo+ID4gPiArICAgICAgICAgICAgICAgaWYgKCFzb2NrX2ZsYWcoc2ssIFNP Q0tfUkNWVFNUQU1QTlMpKSB7Cj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBz b2NrX3RpbWV2YWwgdHY7Cj4gPiA+ICsKPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgc2ti X2dldF9uZXdfdGltZXN0YW1wKHNrYiwgJnR2KTsKPiA+ID4gKyAgICAgICAgICAgICAgICAgICAg ICAgcHV0X2Ntc2cobXNnLCBTT0xfU09DS0VULCBTT19USU1FU1RBTVBfTkVXLAo+ID4gPiArICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplb2YodHYpLCAmdHYpOwo+ID4gPiArICAg ICAgICAgICAgICAgfSBlbHNlIHsKPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0 IF9fa2VybmVsX3RpbWVzcGVjIHRzOwo+ID4gPiArCj4gPiA+ICsgICAgICAgICAgICAgICAgICAg ICAgIHNrYl9nZXRfbmV3X3RpbWVzdGFtcG5zKHNrYiwgJnRzKTsKPiA+ID4gKyAgICAgICAgICAg ICAgICAgICAgICAgcHV0X2Ntc2cobXNnLCBTT0xfU09DS0VULCBTT19USU1FU1RBTVBOU19ORVcs Cj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVvZih0cyksICZ0cyk7 Cj4gPiA+ICsgICAgICAgICAgICAgICB9Cj4gPiA+ICsgICAgICAgfQo+ID4gPiArICAgICAgIGlm ICghc29ja19mbGFnKHNrLCBTT0NLX1JDVlRTVEFNUE5TKSkgewo+ID4gPiArICAgICAgICAgICAg ICAgc3RydWN0IF9fa2VybmVsX29sZF90aW1ldmFsIHR2Owo+ID4gPiArCj4gPiA+ICsgICAgICAg ICAgICAgICBza2JfZ2V0X3RpbWVzdGFtcChza2IsICZ0dik7Cj4gPiA+ICsgICAgICAgICAgICAg ICBwdXRfY21zZyhtc2csIFNPTF9TT0NLRVQsIFNPX1RJTUVTVEFNUF9PTEQsCj4gPiA+ICsgICAg ICAgICAgICAgICAgICAgICAgICBzaXplb2YodHYpLCAmdHYpOwo+ID4gPiArICAgICAgIH0gZWxz ZSB7Cj4gPiA+ICsgICAgICAgICAgICAgICBzdHJ1Y3QgdGltZXNwZWMgdHM7Cj4gPiA+ICsKPiA+ ID4gKyAgICAgICAgICAgICAgIHNrYl9nZXRfdGltZXN0YW1wbnMoc2tiLCAmdHMpOwo+ID4gPiAr ICAgICAgICAgICAgICAgcHV0X2Ntc2cobXNnLCBTT0xfU09DS0VULCBTT19USU1FU1RBTVBOU19P TEQsCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICBzaXplb2YodHMpLCAmdHMpOwo+ID4g PiArICAgICAgIH0KPiA+ID4gK30KPiA+ID4gIC8qCj4gPiA+ICAgKiBjYWxsZWQgZnJvbSBzb2Nr X3JlY3ZfdGltZXN0YW1wKCkgaWYgc29ja19mbGFnKHNrLCBTT0NLX1JDVlRTVEFNUCkKPiA+ID4g ICAqIG9yIHNvY2tfZmxhZyhzaywgU09DS19SQ1ZUU1RBTVBOUykKPiA+ID4gQEAgLTcxOSwxOSAr NzUxLDggQEAgdm9pZCBfX3NvY2tfcmVjdl90aW1lc3RhbXAoc3RydWN0IG1zZ2hkciAqbXNnLCBz dHJ1Y3Qgc29jayAqc2ssCj4gPiA+ICAgICAgICAgICAgICAgICBmYWxzZV90c3RhbXAgPSAxOwo+ ID4gPiAgICAgICAgIH0KPiA+ID4gLSAgICAgICBpZiAobmVlZF9zb2Z0d2FyZV90c3RhbXApIHsK PiA+Cj4gPiBDb25zaWRlcmFibHkgbGVzcyBjb2RlIGNodXJuIGlmIGFkZGluZyBfX3NvY2tfcmVj dl90aW1lc3RhbXBfMjAzOCBhbmQKPiA+IGNhbGxpbmcgdGhhdCBoZXJlOgo+ID4KPiA+ICAgICAg ICAgICAgICAgICAgICBpZiAoc29ja19mbGFnKHNrLCBTT0NLX1RTVEFNUF9ORVcpKQo+ID4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgX19zb2NrX3JlY3ZfdGltZXN0YW1wXzIwMzgobXNnLCBz aywgc2tiKTsKPiA+ICAgICAgICAgICAgICAgICAgICBlbHNlIGlmIC4uLgo+ID4KPiA+IFNhbWUg Zm9yIHRoZSB0Y3AgY2FzZSBhYm92ZSwgcmVhbGx5LCBhbmQgaW4gdGhlIGNhc2Ugb2YgdGhlIG5l eHQgcGF0Y2gKPiA+IGZvciBTT19USU1FU1RBTVBJTkdfTkVXCj4KPiBUaGF0IG5hbWluZyBjb252 ZW50aW9uLCAuLi5fMjAzOCwgaXMgbm90IHRoZSBuaWNlc3QsIG9mIGNvdXJzZS4gVGhhdAo+IGlz IG5vdCB0aGUgcmVsZXZhbnQgYml0IGluIHRoZSBhYm92ZSBjb21tZW50Lgo+Cj4gQ29tZSB0byB0 aGluayBvZiBpdCwgYW5kIHJlbGF0ZWQgdG8gbXkgcXVlc3Rpb24gaW4gcGF0Y2ggMiB3aHkgdGhl Cj4gbmVlZCB0byByZW5hbWUgYXQgYWxsLCBjb3VsZCBhbGwgbmV3IHN0cnVjdHMsIGNvbnN0YW50 cyBhbmQgZnVuY3Rpb25zCj4gYmUgbmFtZWQgY29uc2lzdGVudGx5IHdpdGggNjQgc3VmZml4PyBf X3NvY2tfcmVjdl90aW1lc3RhbXA2NCwKPiBTT19USU1FU1RBTVBJTkc2NCBhbmQgdGltZXZhbDY0 IChpbnN0ZWFkIG9mIHNvY2tfdGltZXZhbCwKPiBpdCBpc24ndCByZWFsbHkgYSBzb2NrIHNwZWNp ZmljIHN0cnVjdCk/Cj4KPiBJIGd1ZXNzIHRoYXQgdGhlcmUgaXMgYSBnb29kIHJlYXNvbiBmb3Ig dGhlIHJlbmFtaW5nIGV4ZXJjaXNlIGFuZAo+IGNvbmRpdGlvbmFsIG1hcHBpbmcgb2YgU09fVElN RVNUQU1QIG9udG8gb2xkIG9yIG5ldyBpbnRlcmZhY2UuCj4gUGxlYXNlIGVsdWNpZGF0ZSBpbiB0 aGUgY29tbWl0IG1lc3NhZ2UuCgpJIHRoaW5rIHRoZXJlIGlzIHNvbWUgY29uZnVzaW9uIGhlcmUu CgpUaGUgZXhpc3RpbmcgdGltZXN0YW1wIG9wdGlvbnM6IFNPX1RJTUVTVEFNUCogZmFpbCB0byBw cm92aWRlIHByb3Blcgp0aW1lc3RhbXBzIGJleW9uZCB5ZWFyIDIwMzggb24gMzIgYml0IEFCSXMu CkJ1dCwgdGhlc2Ugd29yayBmaW5lIG9uIDY0IGJpdCBuYXRpdmUgQUJJcy4KU28gbm93IHdlIG5l ZWQgYSB3YXkgb2YgdXBkYXRpbmcgdGhlc2UgdGltZXN0YW1wcyBzbyB0aGF0IHdlIGRvIG5vdApi cmVhayBleGlzdGluZyB1c2Vyc3BhY2U6IDY0IGJpdCBBQklzIHNob3VsZCBub3QgaGF2ZSB0byBj aGFuZ2UKdXNlcnNwYWNlLCAzMiBiaXQgQUJJcyBzaG91bGQgd29yayBhcyBpcyB1bnRpbCAyMDM4 IGFmdGVyIHdoaWNoIHRoZXkKaGF2ZSBiYWQgdGltZXN0YW1wcy4KU28gd2UgaW50cm9kdWNlIG5l dyB5MjAzOCBzYWZlIHRpbWVzdGFtcCBvcHRpb25zIGZvciAzMiBiaXQgQUJJcy4gV2UKYXNzdW1l IHRoYXQgMzIgYml0IGFwcGxpY2F0aW9ucyB3aWxsIHN3aXRjaCB0byBuZXcgQUJJcyBhdCBzb21l IHBvaW50LApidXQgbGVhdmUgdGhlIG9sZGVyIHRpbWVzdGFtcHMgYXMgaXMuCkkgY2FuIHVwZGF0 ZSB0aGUgY29tbWl0IHRleHQgYXMgcGVyIGFib3ZlLgoKLURlZXBhCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClkyMDM4IG1haWxpbmcgbGlzdApZMjAzOEBs aXN0cy5saW5hcm8ub3JnCmh0dHBzOi8vbGlzdHMubGluYXJvLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3kyMDM4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E77F4C43441 for ; Sun, 25 Nov 2018 05:28:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 93546204FD for ; Sun, 25 Nov 2018 05:28:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kEzbHJfw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93546204FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-parisc-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727288AbeKYQSf (ORCPT ); Sun, 25 Nov 2018 11:18:35 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:44856 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727217AbeKYQSf (ORCPT ); Sun, 25 Nov 2018 11:18:35 -0500 Received: by mail-io1-f67.google.com with SMTP id r200so11435416iod.11; Sat, 24 Nov 2018 21:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6ZDq+TkzUn/G29okEW5qiws/BZ6VkEyzQgI0POq8fhg=; b=kEzbHJfwAO3bNFDX5jEerzuVr38CtCa0HNsxzNCCZi3XLJA985hLZfC6LXcmVHkEXY JzFGSM1VziqJMg7GWZoL121v60MVGNrhgjCgfcglRfSfBUExpcQYcc+sEfCTXgDnrpql EcoGAJt6EVCwE+QYQEHv7i5a2XZMxQPvw9PJBp32rROSAZNvtC+wK5GERi1YdCmHDQ75 ySy72kl0xaOFzHcDsSNU1fqdMybybIyLI3nbZYvmTD1EWRGnqAGAxKhN4SB1yn1DbIWI DI7m7jidGGCcpHk7F2p5l9/JbqdR0VrZV7FQA6P4BUtHHISs1UJyf0TntzzrH2c9X2Hl yCiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6ZDq+TkzUn/G29okEW5qiws/BZ6VkEyzQgI0POq8fhg=; b=Wi7V/HHKFOcs14Xlo3/W+03UX24nL4H+TjDOLQWvlqPdbLZuCagI8u+IfCOozfz4C1 2RK2Z5KeS2YUUjKqDh6ino/wY7Y8GDQKggK3tkYfux+wJZU7CR4XMWThxdR8SZcK2C+/ /FRoO5e7V3VqbOT0G5YUljCSEOQOiSS3B1diUHFbLliovvvcpT5UV0O50Bd6D1TZMPBJ djGXyFtzbF3+f4KHOSKzieGatQLhVBYJzBmeSO1mL0e2NUR/zYqJVB8OHNKnvuV464TW wV7ZT/24CzMx01Vytl6FhFTZXoWTKlb2dzbC9OZfpxdkoM+Vupc3gYDPZ0/WbLtTN0DM NinQ== X-Gm-Message-State: AA+aEWYMUGlTQeZ6o6dIawpuXPDxQm95mVZDOWmVIT/LjYUNcppERPyc 3St4yCpkNJkDh8PChWWE1FOe5oVA1wbffHoECCc= X-Google-Smtp-Source: AFSGD/U1ty8BkP5cpO7vIF/L63LH/hSWCd+dmHYeUvuVs/2kdjL2jXnEzeLz9Aba8BoAkxeLJSkjJVY4IoBl4eEZ+F4= X-Received: by 2002:a6b:3b4f:: with SMTP id i76mr7941350ioa.266.1543123698794; Sat, 24 Nov 2018 21:28:18 -0800 (PST) MIME-Version: 1.0 References: <20181124022035.17519-1-deepa.kernel@gmail.com> <20181124022035.17519-8-deepa.kernel@gmail.com> In-Reply-To: From: Deepa Dinamani Date: Sat, 24 Nov 2018 21:28:07 -0800 Message-ID: Subject: Re: [PATCH 7/8] socket: Add SO_TIMESTAMP[NS]_NEW To: willemdebruijn.kernel@gmail.com Cc: "David S. Miller" , Linux Kernel Mailing List , Linux Network Devel Mailing List , Alexander Viro , Arnd Bergmann , y2038 Mailman List , "James E.J. Bottomley" , Ralf Baechle , rth@twiddle.net, linux-alpha@vger.kernel.org, "open list:RALINK MIPS ARCHITECTURE" , Parisc List , linux-rdma@vger.kernel.org, sparclinux Content-Type: text/plain; charset="UTF-8" Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org > > > + if (type == SO_TIMESTAMP_NEW || type == SO_TIMESTAMPNS_NEW) > > > + sock_set_flag(sk, SOCK_TSTAMP_NEW); > > > + else > > > + sock_reset_flag(sk, SOCK_TSTAMP_NEW); > > > + > > > > if adding a boolean whether the socket uses new or old-style > > timestamps, perhaps fail hard if a process tries to set a new-style > > option while an old-style is already set and vice versa. Also include > > SO_TIMESTAMPING_NEW as it toggles the same option. I do not think this is a problem. Consider this example, if there is a user application with updated socket timestamps is linking into a library that is yet to be updated. Besides, the old timestamps should work perfectly fine on 64 bit arches even beyond 2038. So failing here means adding a bunch of ifdef's to verify it is not executing on 64 bit arch or something like x32. > > > diff --git a/net/socket.c b/net/socket.c > > > index d3defba55547..9abeb6bc9cfe 100644 > > > --- a/net/socket.c > > > +++ b/net/socket.c > > > @@ -699,6 +699,38 @@ static void put_ts_pktinfo(struct msghdr *msg, struct sk_buff *skb) > > > sizeof(ts_pktinfo), &ts_pktinfo); > > > } > > > > > > +static void sock_recv_sw_timestamp(struct msghdr *msg, struct sock *sk, > > > + struct sk_buff *skb) > > > +{ > > > + if (sock_flag(sk, SOCK_TSTAMP_NEW)) { > > > + if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) { > > > + struct sock_timeval tv; > > > + > > > + skb_get_new_timestamp(skb, &tv); > > > + put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP_NEW, > > > + sizeof(tv), &tv); > > > + } else { > > > + struct __kernel_timespec ts; > > > + > > > + skb_get_new_timestampns(skb, &ts); > > > + put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMPNS_NEW, > > > + sizeof(ts), &ts); > > > + } > > > + } > > > + if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) { > > > + struct __kernel_old_timeval tv; > > > + > > > + skb_get_timestamp(skb, &tv); > > > + put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP_OLD, > > > + sizeof(tv), &tv); > > > + } else { > > > + struct timespec ts; > > > + > > > + skb_get_timestampns(skb, &ts); > > > + put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMPNS_OLD, > > > + sizeof(ts), &ts); > > > + } > > > +} > > > /* > > > * called from sock_recv_timestamp() if sock_flag(sk, SOCK_RCVTSTAMP) > > > * or sock_flag(sk, SOCK_RCVTSTAMPNS) > > > @@ -719,19 +751,8 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk, > > > false_tstamp = 1; > > > } > > > - if (need_software_tstamp) { > > > > Considerably less code churn if adding __sock_recv_timestamp_2038 and > > calling that here: > > > > if (sock_flag(sk, SOCK_TSTAMP_NEW)) > > __sock_recv_timestamp_2038(msg, sk, skb); > > else if ... > > > > Same for the tcp case above, really, and in the case of the next patch > > for SO_TIMESTAMPING_NEW > > That naming convention, ..._2038, is not the nicest, of course. That > is not the relevant bit in the above comment. > > Come to think of it, and related to my question in patch 2 why the > need to rename at all, could all new structs, constants and functions > be named consistently with 64 suffix? __sock_recv_timestamp64, > SO_TIMESTAMPING64 and timeval64 (instead of sock_timeval, > it isn't really a sock specific struct)? > > I guess that there is a good reason for the renaming exercise and > conditional mapping of SO_TIMESTAMP onto old or new interface. > Please elucidate in the commit message. I think there is some confusion here. The existing timestamp options: SO_TIMESTAMP* fail to provide proper timestamps beyond year 2038 on 32 bit ABIs. But, these work fine on 64 bit native ABIs. So now we need a way of updating these timestamps so that we do not break existing userspace: 64 bit ABIs should not have to change userspace, 32 bit ABIs should work as is until 2038 after which they have bad timestamps. So we introduce new y2038 safe timestamp options for 32 bit ABIs. We assume that 32 bit applications will switch to new ABIs at some point, but leave the older timestamps as is. I can update the commit text as per above. -Deepa From mboxrd@z Thu Jan 1 00:00:00 1970 From: Deepa Dinamani Date: Sun, 25 Nov 2018 05:28:07 +0000 Subject: Re: [PATCH 7/8] socket: Add SO_TIMESTAMP[NS]_NEW Message-Id: List-Id: References: <20181124022035.17519-1-deepa.kernel@gmail.com> <20181124022035.17519-8-deepa.kernel@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: willemdebruijn.kernel@gmail.com Cc: "David S. Miller" , Linux Kernel Mailing List , Linux Network Devel Mailing List , Alexander Viro , Arnd Bergmann , y2038 Mailman List , "James E.J. Bottomley" , Ralf Baechle , rth@twiddle.net, linux-alpha@vger.kernel.org, "open list:RALINK MIPS ARCHITECTURE" , Parisc List , linux-rdma@vger.kernel.org, sparclinux > > > + if (type = SO_TIMESTAMP_NEW || type = SO_TIMESTAMPNS_NEW) > > > + sock_set_flag(sk, SOCK_TSTAMP_NEW); > > > + else > > > + sock_reset_flag(sk, SOCK_TSTAMP_NEW); > > > + > > > > if adding a boolean whether the socket uses new or old-style > > timestamps, perhaps fail hard if a process tries to set a new-style > > option while an old-style is already set and vice versa. Also include > > SO_TIMESTAMPING_NEW as it toggles the same option. I do not think this is a problem. Consider this example, if there is a user application with updated socket timestamps is linking into a library that is yet to be updated. Besides, the old timestamps should work perfectly fine on 64 bit arches even beyond 2038. So failing here means adding a bunch of ifdef's to verify it is not executing on 64 bit arch or something like x32. > > > diff --git a/net/socket.c b/net/socket.c > > > index d3defba55547..9abeb6bc9cfe 100644 > > > --- a/net/socket.c > > > +++ b/net/socket.c > > > @@ -699,6 +699,38 @@ static void put_ts_pktinfo(struct msghdr *msg, struct sk_buff *skb) > > > sizeof(ts_pktinfo), &ts_pktinfo); > > > } > > > > > > +static void sock_recv_sw_timestamp(struct msghdr *msg, struct sock *sk, > > > + struct sk_buff *skb) > > > +{ > > > + if (sock_flag(sk, SOCK_TSTAMP_NEW)) { > > > + if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) { > > > + struct sock_timeval tv; > > > + > > > + skb_get_new_timestamp(skb, &tv); > > > + put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP_NEW, > > > + sizeof(tv), &tv); > > > + } else { > > > + struct __kernel_timespec ts; > > > + > > > + skb_get_new_timestampns(skb, &ts); > > > + put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMPNS_NEW, > > > + sizeof(ts), &ts); > > > + } > > > + } > > > + if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) { > > > + struct __kernel_old_timeval tv; > > > + > > > + skb_get_timestamp(skb, &tv); > > > + put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP_OLD, > > > + sizeof(tv), &tv); > > > + } else { > > > + struct timespec ts; > > > + > > > + skb_get_timestampns(skb, &ts); > > > + put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMPNS_OLD, > > > + sizeof(ts), &ts); > > > + } > > > +} > > > /* > > > * called from sock_recv_timestamp() if sock_flag(sk, SOCK_RCVTSTAMP) > > > * or sock_flag(sk, SOCK_RCVTSTAMPNS) > > > @@ -719,19 +751,8 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk, > > > false_tstamp = 1; > > > } > > > - if (need_software_tstamp) { > > > > Considerably less code churn if adding __sock_recv_timestamp_2038 and > > calling that here: > > > > if (sock_flag(sk, SOCK_TSTAMP_NEW)) > > __sock_recv_timestamp_2038(msg, sk, skb); > > else if ... > > > > Same for the tcp case above, really, and in the case of the next patch > > for SO_TIMESTAMPING_NEW > > That naming convention, ..._2038, is not the nicest, of course. That > is not the relevant bit in the above comment. > > Come to think of it, and related to my question in patch 2 why the > need to rename at all, could all new structs, constants and functions > be named consistently with 64 suffix? __sock_recv_timestamp64, > SO_TIMESTAMPING64 and timeval64 (instead of sock_timeval, > it isn't really a sock specific struct)? > > I guess that there is a good reason for the renaming exercise and > conditional mapping of SO_TIMESTAMP onto old or new interface. > Please elucidate in the commit message. I think there is some confusion here. The existing timestamp options: SO_TIMESTAMP* fail to provide proper timestamps beyond year 2038 on 32 bit ABIs. But, these work fine on 64 bit native ABIs. So now we need a way of updating these timestamps so that we do not break existing userspace: 64 bit ABIs should not have to change userspace, 32 bit ABIs should work as is until 2038 after which they have bad timestamps. So we introduce new y2038 safe timestamp options for 32 bit ABIs. We assume that 32 bit applications will switch to new ABIs at some point, but leave the older timestamps as is. I can update the commit text as per above. -Deepa