Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp4178860imb; Wed, 6 Mar 2019 07:13:23 -0800 (PST) X-Google-Smtp-Source: APXvYqwIWW5xlbcqurfJPKam7d6TI7EXB9oSo/zPEZ21Wafxnin3zfVeAxAEGuylJ8TdgMpisKRk X-Received: by 2002:a63:6a48:: with SMTP id f69mr6636231pgc.7.1551885203868; Wed, 06 Mar 2019 07:13:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551885203; cv=none; d=google.com; s=arc-20160816; b=zK1fjmxaUy594iaD4L1sRMbVzVupHsnauddEjCRMqa8ZGIp93srfSUydsHIQq2KrtH 1le+T7YRC9IY6WwJotfL3CIml5K5szCx1fgSZE9Wb9ScfPLQG65z1tPWP+8pRJG5GlsV fF9W7pteHe94HxdKe7oR5NiniYPUKC8bF3tjQjn3+QCQKVaaZKFjG6v9BWymDc6XCYHG xPNi+X0ys6MPgH+kDzAZTxSsVSYDiUqHJa3H5s7brVVczJKYaGF3NW/UjUgHWKZGxpYy YlLZp9ub2XsDs2Xq9yrHUgh7wGN5fJQBm6pTtSEKp8DIb79TYJw/CloNXvROg1YNW4lf zn8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=xFAcUPDB5/wpHWSlr6xWOtdLiMPHQKkybpfK7vb+010=; b=m/yKArc+bLbK5CQ9XhFNXzhCZDUTXfWZJ5zUyNu8vdMxgk4M6RYmHxvzKtljUVd+jl 4OSDgV4ZIU1JuY8gIxc3KexsmvN4kqh3SxFvApv2/QFfpa//0rCQZJRbEeDuuFEf46e8 Vfw+CFzUAU4EiIAPqFmfzTml3BJlbRxYaRf1DxU/tLk5k/ARKdmt1tBUiXqKptn2iFIB lUTOLSygwaeKoXhsmlwvx3AGbM6Rwl6LEmCtM94lo2V86UrjjDN6JKHXjHog9ojg3+tH ThHTaA6+jrex6/51bj/ew08BMkbLtd3gLBnokYl+oW5GtX7eo2AsbIWw/tEPf8BlWoaX bfgw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i4si1542308pgs.408.2019.03.06.07.13.08; Wed, 06 Mar 2019 07:13:23 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730061AbfCFM36 (ORCPT + 99 others); Wed, 6 Mar 2019 07:29:58 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:49803 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727222AbfCFM35 (ORCPT ); Wed, 6 Mar 2019 07:29:57 -0500 Received: from p5492e2fc.dip0.t-ipconnect.de ([84.146.226.252] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1h1VgD-0003Rm-9y; Wed, 06 Mar 2019 13:29:49 +0100 Date: Wed, 6 Mar 2019 13:29:48 +0100 (CET) From: Thomas Gleixner To: Miroslav Lichvar cc: John Stultz , Xiongfeng Wang , Stephen Boyd , lkml , Arnd Bergmann Subject: Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow() In-Reply-To: <20190306095442.GM21520@localhost> Message-ID: References: <1551835710-53773-1-git-send-email-wangxiongfeng2@huawei.com> <20190306095442.GM21520@localhost> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 6 Mar 2019, Miroslav Lichvar wrote: > On Tue, Mar 05, 2019 at 05:42:25PM -0800, John Stultz wrote: > > > --- a/kernel/time/ntp.c > > > +++ b/kernel/time/ntp.c > > > @@ -677,6 +677,8 @@ static inline void process_adjtimex_modes(const struct timex *txc, s32 *time_tai > > > > > > if (txc->modes & ADJ_MAXERROR) > > > time_maxerror = txc->maxerror; > > > + if (time_maxerror > NTP_PHASE_LIMIT) > > > + time_maxerror = NTP_PHASE_LIMIT; > > > > This looks sane to me. > > Acked-by: John Stultz > > > > Though it makes me wonder a bit more about the sanity checking on the > > other parameters passed via adjtimex(), tick_usec for instance looks > > like it could be similarly problematic. > > The tick length is checked earlier in timekeeping_validate_timex(), so > that should be ok. > > What I'd like to see clamped is the system time itself. ktime_t > overflows on Apr 11 2262. clock_settime() and adjtimex(ADJ_SETOFFSET) > can set the time close to the overflow and let everything break. > > Boot a VM and try this: > > # date -s 'Apr 11 23:47:15 UTC 2262' So once Arnd is done with y2038, we'll ask him to look into y2262 :) Seriously, yes we should do clamping there. Thanks, tglx