Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1962401yba; Mon, 15 Apr 2019 01:57:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqyOnWdbdVfeEEP4eA9Rv8Z6f+nqSLEVPqNaYI0O7CAeMxWoz0FHkCr+TD7qMZVXGl9GgdO3 X-Received: by 2002:a63:fc43:: with SMTP id r3mr68012517pgk.44.1555318668065; Mon, 15 Apr 2019 01:57:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555318668; cv=none; d=google.com; s=arc-20160816; b=b4AhVm07XXQBzJ7Lqc8sH9u/qYWHpCL2V8Vo5+k5SYi9KtPjnB3U4lFOkd7eDnpvRZ T4fTdZeDxq9X4Og3gjxVklh++t3USKJ02dmsT6osqMm3krU6wv/eLd+VGs5vTKTgf/J3 vdYPzJCTlhhxeLnYGWGyR+AjepEHtYhDEECJz11CHFTepgQjoDRzmTQeHBWdB/ev7RHD 24yhnwC7+etfHfrSgtsvwOX7wHYhKCnFHF7DymEXL3135BTdFe2sBeVe4VwP6Ecr2ZrG 40WguF+sIqEpyHwjBdKAI31wdv25vsiVVVEDxULW3QxE1pcIbit/En7/t9cPqFnFy/5g hygA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=v77EdpIp8nymidQ/+hcBZE9dd5mYGLzXIX4OTy11Zi0=; b=Rjjcnigr61Y1axOmllwsoAMxzi+ulLJQJ6haGWx3b5ibcfG47G/1gXU3SrUixafio+ unR4TTKtFTz248tGVgzbVWYp+1TtodCsPeJWWVtL/pMGFgLOyShSox5Xkuz5uPhDwJmr cT3Qd8Mqv7UB53v71vKXVuJ1m1UQSieJ+fyGHYrmecSDv/7/5oXD+qqOytWFXPvNW+Jb mUqE8Cc8OAbDbaE3iq4kPpNbn8EdprDL3+2H8U9k1X9Mt0sWAZSyQfqTS9Dy0sQEHWXU sPFCoeHV79POHm/1IWitIh/A4M6IyrtdFepemwWlG5pduA1pMbCjmAmnZTCRCzCHgyPF qCkg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h185si46529359pfc.241.2019.04.15.01.57.32; Mon, 15 Apr 2019 01:57:48 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726537AbfDOI4q (ORCPT + 99 others); Mon, 15 Apr 2019 04:56:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39164 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726277AbfDOI4p (ORCPT ); Mon, 15 Apr 2019 04:56:45 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 502AF3082211; Mon, 15 Apr 2019 08:56:45 +0000 (UTC) Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A7FD05D71A; Mon, 15 Apr 2019 08:56:43 +0000 (UTC) Date: Mon, 15 Apr 2019 10:56:41 +0200 From: Miroslav Lichvar To: Thomas Gleixner Cc: Ondrej Mosnacek , Roman Zippel , John Stultz , Stephen Boyd , Andrew Morton , Linux kernel mailing list Subject: Re: kernel/time/ntp.c: Possible off-by-one error in TAI range check? Message-ID: <20190415085641.GI28203@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Mon, 15 Apr 2019 08:56:45 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 15, 2019 at 10:09:43AM +0200, Thomas Gleixner wrote: > > On Mon, Apr 8, 2019 at 10:47 AM Ondrej Mosnacek wrote: > > > Commit 153b5d054ac2 ("ntp: support for TAI") added a possibility to > > > change the TAI offset from userspace via adjtimex(2). The code checks > > > if the input value (txc->constant) is greater than 0 and if it is not, > > > then it doesn't modify the value. Ignoring the fact that this check > > > should probably be in timekeeping_validate_timex() and cause -EINVAL > > > to be returned when false, I find it strange that the check doesn't > > > allow to set the value to 0, which seems to be the default value... > > > > > > Was this behavior intended or should the code actually check for > > > txc->constant >= 0 instead of txc->constant > 0? I guess zero here means "unknown" and maybe the intention was to not allow setting the offset to an unknown value once it has been set to a valid value. The trouble is that after inserting a leap second the offset may change from zero to one. I think it should be changed to allow setting the offset to zero. -- Miroslav Lichvar