netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Deepa Dinamani <deepa.kernel@gmail.com>,
	davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: y2038@lists.linaro.org, viro@zeniv.linux.org.uk, arnd@arndb.de
Subject: Re: [PATCH] sock: Make sock->sk_tstamp thread-safe
Date: Sat, 22 Dec 2018 23:31:07 -0800	[thread overview]
Message-ID: <e4f80b85-eafb-691d-2ebc-056d565f5d62@gmail.com> (raw)
In-Reply-To: <20181221202733.19627-1-deepa.kernel@gmail.com>



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.

_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

  parent reply	other threads:[~2018-12-23  7:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21 20:27 [PATCH] sock: Make sock->sk_tstamp thread-safe Deepa Dinamani
2018-12-22 13:29 ` Arnd Bergmann
2018-12-22 16:34   ` Deepa Dinamani
2018-12-22 23:03 ` David Miller
2018-12-23  7:31 ` Eric Dumazet [this message]
2018-12-23 18:50   ` Deepa Dinamani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e4f80b85-eafb-691d-2ebc-056d565f5d62@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=deepa.kernel@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).