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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 E00BBC43387 for ; Sun, 23 Dec 2018 07:31:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A709D21905 for ; Sun, 23 Dec 2018 07:31:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KGKr19S5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726927AbeLWHbM (ORCPT ); Sun, 23 Dec 2018 02:31:12 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:36383 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726338AbeLWHbM (ORCPT ); Sun, 23 Dec 2018 02:31:12 -0500 Received: by mail-wr1-f67.google.com with SMTP id u4so9054157wrp.3; Sat, 22 Dec 2018 23:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=b4BSxs5OmDvkxRnOxnJFJ3IX148xL98kma57v+jE6f8=; b=KGKr19S5Q6Zsr2+Zatjr0Ky/EXlq91lwkOkc8yZLkvpHUDGsdp3cLRQ0XzbY7RJGCo 4G/nuM/Whb03XNP8LnM4Ubc9odo90oLYxsov9sSBUVKqYoqcM6RC3B9XKk1Yu9VB1uZo 4t4m36O8Hi/6duuklXsC2x8dT3EdBF6g9tR4Nj0k93/8ByBaPKR74ISlqLATMrEB1lMp DY3uNa1A26RdX4+rWSAJpALVqanOksgIC6tbNWfsMnUSOKAdWkouRj9I6GBw9ScU9IRZ OwHcLNQs5M0UPhHin2kV5t+i0It30adLB/zusK9SNJEZt6G3WdhXD/pz4d37myGEVPCp gs8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b4BSxs5OmDvkxRnOxnJFJ3IX148xL98kma57v+jE6f8=; b=t8f+YWB+g9eFzT/yeh3wd/ZX1d54yOLktL/EOqKN3MYDfdtOe27vwmeumXeq7ObIp0 mHGxhkmmNwEHbXG0iC4buT3zfgrfYHlpFjP3e++jVMF3CGN9/XXgggWA8K/n64hOBTfX E9skmv3hwsB9CDd57s3AzFaf//WFWIJjnMZWGhDthUUbCOCUpvDzGzGD0nWjEoJm332H R9P1NsdnPtTvF9w9hZrik6X92GF8EBigMJoUqZkw80XEHVzjSM30pEg2xyGSQGnl5fWM y+/JZdBxZOGPpZ2bhH25CcPFPSnOheQvz5Q7rFGJ4db2EnV+hinLIcHfeRm0ps18hzBX EoYw== X-Gm-Message-State: AJcUukftDxxcc5vwPUJMP18CBJudPxg1fMOqYgbZIXuXu+wnEzEg4hfW KUbuyxEOFfKPCvWB6yPA35s= X-Google-Smtp-Source: ALg8bN5MbZ/GARwPkxGhoyKzj0duytZ7tW7D9sNFmXrS8Uku/AxdFl+KN+qfaNlt80cS/ygQxvWEXA== X-Received: by 2002:a5d:5208:: with SMTP id j8mr8459652wrv.188.1545550270329; Sat, 22 Dec 2018 23:31:10 -0800 (PST) Received: from [192.168.8.147] (140.15.136.77.rev.sfr.net. [77.136.15.140]) by smtp.gmail.com with ESMTPSA id 126sm31974209wmx.26.2018.12.22.23.31.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Dec 2018 23:31:09 -0800 (PST) Subject: Re: [PATCH] sock: Make sock->sk_tstamp thread-safe To: Deepa Dinamani , davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: viro@zeniv.linux.org.uk, arnd@arndb.de, y2038@lists.linaro.org References: <20181221202733.19627-1-deepa.kernel@gmail.com> From: Eric Dumazet Message-ID: Date: Sat, 22 Dec 2018 23:31:07 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181221202733.19627-1-deepa.kernel@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/21/2018 12:27 PM, Deepa Dinamani wrote: > Al Viro mentioned that there is probably a race condition > lurking in accesses of sk_tstamp on 32-bit machines. > > sock->sk_tstamp is of type ktime_t which is always an s64. > On a 32 bit architecture, we might run into situations of > unsafe access as the access to the field becomes non atomic. > > Use seqlocks for synchronization. > This allows us to avoid using spinlocks for readers as > readers do not need mutual exclusion. > Hi Deepa Please come up with something that has zero added costs for 64bit kernels. Most of us do not really care about 32bit kernels anymore, so we do not want to slow down 64bits kernels for such things. Look at include/linux/u64_stats_sync.h for initial thoughts. Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH] sock: Make sock->sk_tstamp thread-safe Date: Sat, 22 Dec 2018 23:31:07 -0800 Message-ID: References: <20181221202733.19627-1-deepa.kernel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: y2038@lists.linaro.org, viro@zeniv.linux.org.uk, arnd@arndb.de To: Deepa Dinamani , davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: In-Reply-To: <20181221202733.19627-1-deepa.kernel@gmail.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: y2038-bounces@lists.linaro.org Sender: "Y2038" List-Id: netdev.vger.kernel.org CgpPbiAxMi8yMS8yMDE4IDEyOjI3IFBNLCBEZWVwYSBEaW5hbWFuaSB3cm90ZToKPiBBbCBWaXJv IG1lbnRpb25lZCB0aGF0IHRoZXJlIGlzIHByb2JhYmx5IGEgcmFjZSBjb25kaXRpb24KPiBsdXJr aW5nIGluIGFjY2Vzc2VzIG9mIHNrX3RzdGFtcCBvbiAzMi1iaXQgbWFjaGluZXMuCj4gCj4gc29j ay0+c2tfdHN0YW1wIGlzIG9mIHR5cGUga3RpbWVfdCB3aGljaCBpcyBhbHdheXMgYW4gczY0Lgo+ IE9uIGEgMzIgYml0IGFyY2hpdGVjdHVyZSwgd2UgbWlnaHQgcnVuIGludG8gc2l0dWF0aW9ucyBv Zgo+IHVuc2FmZSBhY2Nlc3MgYXMgdGhlIGFjY2VzcyB0byB0aGUgZmllbGQgYmVjb21lcyBub24g YXRvbWljLgo+IAo+IFVzZSBzZXFsb2NrcyBmb3Igc3luY2hyb25pemF0aW9uLgo+IFRoaXMgYWxs b3dzIHVzIHRvIGF2b2lkIHVzaW5nIHNwaW5sb2NrcyBmb3IgcmVhZGVycyBhcwo+IHJlYWRlcnMg ZG8gbm90IG5lZWQgbXV0dWFsIGV4Y2x1c2lvbi4KPgoKSGkgRGVlcGEKClBsZWFzZSBjb21lIHVw IHdpdGggc29tZXRoaW5nIHRoYXQgaGFzIHplcm8gYWRkZWQgY29zdHMgZm9yIDY0Yml0IGtlcm5l bHMuCgpNb3N0IG9mIHVzIGRvIG5vdCByZWFsbHkgY2FyZSBhYm91dCAzMmJpdCBrZXJuZWxzIGFu eW1vcmUsIHNvIHdlIGRvIG5vdCB3YW50IHRvIHNsb3cKZG93biA2NGJpdHMga2VybmVscyBmb3Ig c3VjaCB0aGluZ3MuCgpMb29rIGF0IGluY2x1ZGUvbGludXgvdTY0X3N0YXRzX3N5bmMuaCBmb3Ig aW5pdGlhbCB0aG91Z2h0cy4KClRoYW5rcy4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fClkyMDM4IG1haWxpbmcgbGlzdApZMjAzOEBsaXN0cy5saW5hcm8u b3JnCmh0dHBzOi8vbGlzdHMubGluYXJvLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3kyMDM4Cg==