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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 91156C282DA for ; Wed, 17 Apr 2019 16:19:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A9D520674 for ; Wed, 17 Apr 2019 16:19:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732731AbfDQQTo (ORCPT ); Wed, 17 Apr 2019 12:19:44 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:40300 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729641AbfDQQTo (ORCPT ); Wed, 17 Apr 2019 12:19:44 -0400 Received: by mail-qt1-f194.google.com with SMTP id x12so27995835qts.7; Wed, 17 Apr 2019 09:19:43 -0700 (PDT) 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=M1b9GSK1VJr1GL9RcS5con8Prr8JPtAwFnxmkS4Pf3c=; b=QVRgoRJl69TlVpIqeDuMloOV/KRdBD3GdGM/J92PBdvuo+tmOpyzWCkreutZ9hGZUI 1tVUd+3Hm7lDByvoUy0NBIsG2W1YP1kpskPQanxulRzWO4jftPNn0ysSzjq4wZOABMFL 99eXhf415M5Yhu3aCdwNk5jyLmyf4PplLyEzb36DXN+BHnnnMDBhKTVd3ubxiV/PWqqx pSumolFuSGzTJViXuKSZ3bCOaWwP0MjPmdrxMWbx6K6baGUJ/Gei8zToIQnb3F+tDtrP T7lJNDfPsUxSEYfsAC+Rikj4IIYXHdWnkTQPkc0qhAcmC0sqLIX+vIow3yApBDIqaQ6I mvtQ== X-Gm-Message-State: APjAAAXBDzPJByR/2BuwjJze6GhklV7YGwWvVZpQgPEWoh2ez4mQwn+j WM4/1REhYQhoVqbgfFGsrZ/4T1k7XmloIJZOKWQ= X-Google-Smtp-Source: APXvYqwvqBeAhXMpfw61DPYGN3eB/GwOK6eBSVxzTm/UN7mdMOU0P+3NWtw7afLpPAQNzyglYzTdCGJXNVsqdjN3Cb8= X-Received: by 2002:a0c:ba10:: with SMTP id w16mr72768455qvf.115.1555517982549; Wed, 17 Apr 2019 09:19:42 -0700 (PDT) MIME-Version: 1.0 References: <20190416203620.539628-1-arnd@arndb.de> In-Reply-To: From: Arnd Bergmann Date: Wed, 17 Apr 2019 18:19:25 +0200 Message-ID: Subject: Re: [PATCH net-next 1/3] net: rework SIOCGSTAMP ioctl handling To: Willem de Bruijn Cc: "David S. Miller" , Ralf Baechle , Marcel Holtmann , Johan Hedberg , Oliver Hartkopp , Marc Kleine-Budde , Gerrit Renker , Alexander Aring , Stefan Schmidt , Alexey Kuznetsov , Hideaki YOSHIFUJI , Vlad Yasevich , Neil Horman , Marcelo Ricardo Leitner , Andrew Hendry , Eric Dumazet , Willem de Bruijn , Deepa Dinamani , Network Development , LKML , linux-hams@vger.kernel.org, Bluez mailing list , linux-can@vger.kernel.org, dccp@vger.kernel.org, linux-wpan@vger.kernel.org, linux-sctp@vger.kernel.org, linux-x25@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org On Wed, Apr 17, 2019 at 4:46 PM Willem de Bruijn wrote: > On Tue, Apr 16, 2019 at 4:38 PM Arnd Bergmann wrote: > > The SIOCGSTAMP/SIOCGSTAMPNS ioctl commands are implemented by many > > socket protocol handlers, and all of those end up calling the same > > sock_get_timestamp()/sock_get_timestampns() helper functions, which > > results in a lot of duplicate code. > > > > With the introduction of 64-bit time_t on 32-bit architectures, this > > gets worse, as we then need four different ioctl commands in each > > socket protocol implementation. > > > > To simplify that, let's add a new .gettstamp() operation in > > struct proto_ops, and move ioctl implementation into the common > > sock_ioctl()/compat_sock_ioctl_trans() functions that these all go > > through. > > > > We can reuse the sock_get_timestamp() implementation, but generalize > > it so it can deal with both native and compat mode, as well as > > timeval and timespec structures. > > > > Acked-by: Stefan Schmidt > > Link: https://lore.kernel.org/lkml/CAK8P3a038aDQQotzua_QtKGhq8O9n+rdiz2=WDCp82ys8eUT+A@mail.gmail.com/ > > Signed-off-by: Arnd Bergmann > > --- > > v2: reworked to not break sparc64 support > > From the discussion of v1 I thought you planned to unconditionally > call sock_gettstamp() for all protocols, avoiding the need to plumb in > all these new callbacks? > > That is more concise, though this closer to the existing behavior. So, > fine either way. Thanks for the reminder. I have definitely waited too long before revisiting this series, and only had a vague recollection of that discussion but could not find it in the logs (found it now, and the Link I quoted...). I would prefer to get this series into the coming merge window, and probably don't have time to rework it completely by then, so I hope the current version is ok. I also found your comment on lock_sock(), which could be easily added inside of sock_gettstamp() if you think we should have that. There is one more issue I just noticed (I dropped the necessary sock_read_timestamp()), so I have to repost the series anyway to fix that. Arnd