Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp19717imm; Thu, 30 Aug 2018 13:12:25 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZfwPZTAlZYFop2UNicax4behLqQaAW9Sg+qkI4A73F29ASV11z8Y0hTRxZuWtN+Iesq8Xp X-Received: by 2002:a63:a441:: with SMTP id c1-v6mr11295760pgp.182.1535659945600; Thu, 30 Aug 2018 13:12:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535659945; cv=none; d=google.com; s=arc-20160816; b=a2YvXlQ22simw4Ab93zlA7TeSXLrThzv2KBpPOD3ADEPL/77NisD8t7amOv8bx2a7M aWSMw3WmLb23r9ukbU1SiKX9ryzo9VW/cI0fk7rMgo3kjtl/PNhTdUuKfqP14DuPYhfP ChDG7e9xR28lUTNgWNnGETkesFXZLRhqvq2iTL+18RWEZItW18ERi/Zi7kD+AViun2QR nBQo1S/E4rrRl896MgGZm8MaE8BlZjA2HbC214xJKW7xYAuEBCvbY8SyhpL/6kBuPaV5 JedGftu6sVTLe6XFzKx1yQvWJf3n+oaASP1QFEnHTB8zI/LOfcwkMvxsFWDKCotr0/fK 1DvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=CCY71oDba5HfDH1IH+EInLZWKOqhzUa8I+3WpzhWLg8=; b=N0VLlEpFBFa0C38TpJ4PKszZ4D1oIuIM52Qb2aFvET2Q6XAaExlYfaUaHvUe+WQpps Ui3trlHx5stcSrWCWGTHx4z+lDYStUJ0wJD8wVGU2z3rm4pxfMxjvqPFfZiXW+xHWzVG p5KGZ6nGgvNt1cI7JMEbIkPkcxmmRIAH+oWGfNSD3kttJae5SooXgKRBV0eJElEbWska 5ygUfDq84QK7nUmIqeTCiIeirelMOKi0MGwfzmwQIhRLcXxcwUVa/CXvNFPt5Xi6TpFb iG/nhbakakmJE3MpMZBzmg9ru042NvgFk2H2cVCJLWELBlC/OMM3A89w17OgwtHCQ3vf 291w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=RNyR9Kwm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k193-v6si7225878pge.4.2018.08.30.13.12.00; Thu, 30 Aug 2018 13:12:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=RNyR9Kwm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727250AbeHaAOD (ORCPT + 99 others); Thu, 30 Aug 2018 20:14:03 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:42375 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725836AbeHaAOC (ORCPT ); Thu, 30 Aug 2018 20:14:02 -0400 Received: by mail-ed1-f67.google.com with SMTP id l5so4806845edw.9; Thu, 30 Aug 2018 13:10:08 -0700 (PDT) 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=CCY71oDba5HfDH1IH+EInLZWKOqhzUa8I+3WpzhWLg8=; b=RNyR9KwmkOkwufC92/PUcVJvYMEoC/GfoMe4YbEtWDznIYGl5ACD2Mclt0I9D5focF o4a459FnkNUg2xGQqI3hHxz7yz7hUSC0pPINYV1AMNTZF/c/r/N/bgKcL6hTnlyFSs3o KGL3dxOX/wDL3CcsRtaz2XZGT3sJznP5C7Tet61otuAQ2tzxg5cNE+SqJDRuUtxdgfm1 wMehmjlWCHaP+NSPi/3bhMg2AjHDhR28xIhe+XwxPa9TW/BRtDMnexjt2hPQE6hBtwPH +MACW+95qLGFDzoXp0EMc9Ta5/I22wta0q+kFMOm63sE0/JqwApivXeJp+J9SzLl4xL6 tsGg== 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=CCY71oDba5HfDH1IH+EInLZWKOqhzUa8I+3WpzhWLg8=; b=hFtn+n+X2lXHe4jDNZgqZ8rI3uGIUUoMBGptaRSTGFSuXDiiMTFZHWRvNmWCy7vCKR oo6lyQbubLJj3PNEIXrHTbQotaVGUR3pKS2HdnlPJZ/WdByehOss0hUYqi6T2Kugb35/ eMNbp6ePI4Gf7+Yyit5AIoV908oT0aim4fKUat0ewC31Ha23R2V/C0Cx8iIWUOHTAXOp w+0FEyd2QgRgjeVUqmscB9frtmoiiUXu4VmGeGTKEuz5jEeqCOpFjT5plrNHiYyK1TbD xI2BQc7PKvuXfaikdpdgMV/ChTzd0ZTryoeDXVU/nDDqCU2dyKom2YylDM4bK/Fjvr6P YHpg== X-Gm-Message-State: APzg51A89vL0ezOJmWeeWGGZOjdZZ9UsYuZ/d72B6Y5GiT73bXN55LqM jlK9t/RbPjKD2qQ+FGnok0fFqyGGAKzc7XKuvhHnNMod X-Received: by 2002:a50:fc03:: with SMTP id i3-v6mr14824859edr.85.1535659807918; Thu, 30 Aug 2018 13:10:07 -0700 (PDT) MIME-Version: 1.0 References: <20180829130308.3504560-1-arnd@arndb.de> In-Reply-To: <20180829130308.3504560-1-arnd@arndb.de> From: Willem de Bruijn Date: Thu, 30 Aug 2018 16:09:31 -0400 Message-ID: Subject: Re: [PATCH net-next 1/3] net: rework SIOCGSTAMP ioctl handling To: Arnd Bergmann Cc: Network Development , David Miller , linux-arch@vger.kernel.org, y2038 Mailman List , Eric Dumazet , Willem de Bruijn , LKML , linux-hams@vger.kernel.org, linux-bluetooth@vger.kernel.org, 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 29, 2018 at 9:05 AM 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. > > Signed-off-by: Arnd Bergmann This also will simplify fixing a recently reported race condition with sock_get_timestamp [1]. That calls sock_enable_timestamp, which modifies sk->sk_flags, without taking the socket lock. Currently some callers of sock_get_timestamp hold the lock (ax25, netrom, qrtr), many don't. See also how this patch removes the lock_sock in the netrom case. Moving the call to sock_gettstamp outside the protocol handlers will allow taking the lock inside the function. If this is the only valid implementation of .gettstamp, the indirect call could be avoided in favor of a simple branch. Thanks, Acked-by: Willem de Bruijn [1] http://lkml.kernel.org/r/20180518080308.GA28587@dragonet.kaist.ac.kr