From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752620AbdFMKad (ORCPT ); Tue, 13 Jun 2017 06:30:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40850 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752078AbdFMKaa (ORCPT ); Tue, 13 Jun 2017 06:30:30 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1E8DD793E9 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mlichvar@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1E8DD793E9 Date: Tue, 13 Jun 2017 12:30:26 +0200 From: Miroslav Lichvar To: John Stultz Cc: lkml , Thomas Gleixner , Ingo Molnar , Richard Cochran , Prarit Bhargava , Stephen Boyd , Kevin Brodsky , Will Deacon , Daniel Mentz , "stable #4 . 8+" Subject: Re: [PATCH 2/3 v3] time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting Message-ID: <20170613103026.GF4221@localhost> References: <1496965462-20003-1-git-send-email-john.stultz@linaro.org> <1496965462-20003-3-git-send-email-john.stultz@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1496965462-20003-3-git-send-email-john.stultz@linaro.org> User-Agent: Mutt/1.8.0 (2017-02-23) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 13 Jun 2017 10:30:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 08, 2017 at 04:44:21PM -0700, John Stultz wrote: > Due to how the MONOTONIC_RAW accumulation logic was handled, > there is the potential for a 1ns discontinuity when we do > accumulations. This small discontinuity has for the most part > gone un-noticed, but since ARM64 enabled CLOCK_MONOTONIC_RAW > in their vDSO clock_gettime implementation, we've seen failures > with the inconsistency-check test in kselftest. > > This patch addresses the issue by using the same sub-ns > accumulation handling that CLOCK_MONOTONIC uses, which avoids > the issue for in-kernel users. The patch looks good to me and in testing on x86_64 I didn't see any issues with the CLOCK_MONOTONIC_RAW clock. Thanks, -- Miroslav Lichvar