netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Harsh Jain <harsh@chelsio.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Atul Gupta <atul.gupta@chelsio.com>,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	Michael Werner <werner@chelsio.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH] [RESEND, net-next, v2] tcp: use monotonic timestamps for PAWS
Date: Wed, 11 Jul 2018 05:17:47 -0700	[thread overview]
Message-ID: <ff297506-d0eb-f242-b623-3b158dbabe0c@gmail.com> (raw)
In-Reply-To: <20180711101757.3929777-1-arnd@arndb.de>



On 07/11/2018 03:16 AM, Arnd Bergmann wrote:
> Using get_seconds() for timestamps is deprecated since it can lead
> to overflows on 32-bit systems. While the interface generally doesn't
> overflow until year 2106, the specific implementation of the TCP PAWS
> algorithm breaks in 2038 when the intermediate signed 32-bit timestamps
> overflow.
> 
> A related problem is that the local timestamps in CLOCK_REALTIME form
> lead to unexpected behavior when settimeofday is called to set the system
> clock backwards or forwards by more than 24 days.
> 
> While the first problem could be solved by using an overflow-safe method
> of comparing the timestamps, a nicer solution is to use a monotonic
> clocksource with ktime_get_seconds() that simply doesn't overflow (at
> least not until 136 years after boot) and that doesn't change during
> settimeofday().
> 
> To make 32-bit and 64-bit architectures behave the same way here, and
> also save a few bytes in the tcp_options_received structure, I'm changing
> the type to a 32-bit integer, which is now safe on all architectures.

Nit: This is only manipulated under socket lock protection, so it is safe even on 
32bit kernels.

> 
> Finally, the ts_recent_stamp field also (confusingly) gets used to store
> a jiffies value in tcp_synq_overflow()/tcp_synq_no_recent_overflow().
> This is currently safe, but changing the type to 32-bit requires
> some small changes there to keep it working.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: use time_before32()/time_after32() everywhere as suggested
>     Eric Dumazet in https://lore.kernel.org/lkml/67ebb94d-c73f-6c9f-493b-00c86f595120@gmail.com/

SGTM, thanks Arnd

Signed-off-by: Eric Dumazet <edumazet@google.com>

  reply	other threads:[~2018-07-11 12:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-11 10:16 [PATCH] [RESEND, net-next, v2] tcp: use monotonic timestamps for PAWS Arnd Bergmann
2018-07-11 12:17 ` Eric Dumazet [this message]
2018-07-12 21:50 ` David Miller

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=ff297506-d0eb-f242-b623-3b158dbabe0c@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=arnd@arndb.de \
    --cc=atul.gupta@chelsio.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gustavo@embeddedor.com \
    --cc=harsh@chelsio.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=werner@chelsio.com \
    --cc=yoshfuji@linux-ipv6.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).