From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0CE2C3A5A0 for ; Mon, 19 Aug 2019 14:53:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D0686206BB for ; Mon, 19 Aug 2019 14:53:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726670AbfHSOxA (ORCPT ); Mon, 19 Aug 2019 10:53:00 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:47482 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725536AbfHSOw7 (ORCPT ); Mon, 19 Aug 2019 10:52:59 -0400 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hzj1j-00060d-P9; Mon, 19 Aug 2019 16:52:55 +0200 Date: Mon, 19 Aug 2019 16:52:55 +0200 (CEST) From: Thomas Gleixner To: Arul Jeniston cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, arul_mc@dell.com Subject: Re: [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read function. In-Reply-To: Message-ID: References: <20190816083246.169312-1-arul.jeniston@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Arul, On Mon, 19 Aug 2019, Arul Jeniston wrote: > > 1) TSCs are out of sync or affected otherwise > > If the TSC clock is unstable and not synchronized, Linux kernel throws > dmesg logs and changes the current clock source to next best timer > (hpet). But we didn't see these logs in any of the 10000 units. Did you see "TSC ADJUST" entries? > > 2) Timekeeping has a bug. > > As per our analysis, > > After the timer expiry, after tsc is read in hrtimer_forward_now() > -->ktime_get()-->timekeeping_get_ns(), if the current thread (t1) is > interrupted and/or some other thread running in different CPU (t2) > updates timekeeper cycle_last value with a latest tsc than t1, > clocksource_delta() and timekeeping_get_delta() would return 0. > Eventually timekeeping_delta_to_ns() would return a smaller value > based on the other two parameters (mult, xtime_nsec). If > base(timekeeper.tkr_mono.base) is not updated all this time, then > ktime_get() could return a value lesser than expiry time. > Note: CONFIG_DEBUG_TIMEKEEPING is not configured in our system. Sorry, but your analysis is wrong. The timekeeping code does never return time going backwards, except for the case where the hardware is buggered and the failure cannot be detected. But for the above scenario: ktime_get() do { seq = read_seqcount_begin(&tk_core.seq); base = tk->tkr_mono.base; nsecs = timekeeping_get_ns(&tk->tkr_mono); } while (read_seqcount_retry(&tk_core.seq, seq)); So if the interrupt which updates the timekeeper hits in the middle of timekeeping_get_ns() then the result is discarded because the sequence count changed and read_seqcount_retry() returns true. So it takes another round which will be perfectly aligned with the updated time keeper. Thanks, tglx