From: Thomas Gleixner <tglx@linutronix.de> To: Arul Jeniston <arul.jeniston@gmail.com> 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. Date: Fri, 16 Aug 2019 23:17:26 +0200 (CEST) Message-ID: <alpine.DEB.2.21.1908162255400.1923@nanos.tec.linutronix.de> (raw) In-Reply-To: <CACAVd4gHQ+_y5QBSQm3pMFHKrVgvvJZAABGvtp6=qt3drVXpTA@mail.gmail.com> Arul, On Fri, 16 Aug 2019, Arul Jeniston wrote: > Adding few more data points... Can you please trim your replies? It's annoying to have to search for the meat of your mail by scrolling down several pages and paying attention to not skip something useful inside of useless information. > On Fri, Aug 16, 2019 at 10:25 PM Arul Jeniston <arul.jeniston@gmail.com> wrote: > > On Fri, Aug 16, 2019 at 4:15 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > > > We use CLOCK_REALTIME while creating timer_fd. > > Can read() on timerfd return 0 when the clock is set to CLOCK_REALTIME? As CLOCK_REALTIME is subject to be set by various mechanisms, yes. See timerfd_clock_was_set(). If that's the case, your application is missing something. But see below ... > > We have Intel rangely 4 cpu system running debian stretch linux > > kernel. The current clock source is set to tsc. During our testing, we > > observed the time drifts backward occasionally. Through kernel > > instrumentation, we observed, sometimes clocksource_delta() finds the > > current time lesser than last time. and returns 0 delta. That has absolutely nothing to do with CLOCK_REALTIME. Your machines TSC is either going backwards or not synchronized between cores. Hint: Dell has a track record of BIOS doing the wrong things to TSC in order to hide their 'value add' features stealing CPU time. > This causes the following code flow to return a time which is lesser > than previously fetched time. > ktime_get()-->timekeeping_get_ns()-->timekeeping_get_delta()-->clocksource_delta() ktime_get() is CLOCK_MONOTONIC and not CLOCK_REALTIME. > Since ktime_get() returns a time which is lesser than the expiry time, > hrtimer_forward_now return 0. > This in-turn causes timerfd_read to return 0. > Is it not a bug? It's a bug, but either a hardware or a BIOS bug and you are trying to paper over it at the place where you observe the symptom, which is obviously the wrong place because: 1) Any other time related function even in timerfd is affected as well 2) We do not cure symptoms, we cure the root cause. And clearly the root cause hase not been explained and addressed. Thanks, tglx
next prev parent reply index Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-16 8:32 [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read function. 'hrtimer_forward_now()' returns zero due to bigger backward time drift. This causes timerfd_read to return 0. As per man page, read on timerfd is not expected to return 0. This patch fixes this problem. Signed-off-by: Arul Jeniston <arul.jeniston@gmail.com> arul.jeniston 2019-08-16 9:05 ` [PATCH] FS: timerfd: [Trimmed unreadable long subject line ] Thomas Gleixner 2019-08-16 10:22 ` [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read function Arul Jeniston 2019-08-16 10:45 ` Thomas Gleixner 2019-08-16 16:55 ` Arul Jeniston 2019-08-16 17:00 ` Arul Jeniston 2019-08-16 21:17 ` Thomas Gleixner [this message] [not found] ` <CACAVd4hT6QYtgtDsBcgy7c_s9WVBAH+1m0r5geBe7BUWJWYhbA@mail.gmail.com> 2019-08-17 19:23 ` Thomas Gleixner 2019-08-19 6:07 ` Arul Jeniston 2019-08-19 8:04 ` Thomas Gleixner 2019-08-19 14:25 ` Arul Jeniston 2019-08-19 14:52 ` Thomas Gleixner 2019-08-19 15:26 ` Arul Jeniston 2019-08-19 15:59 ` Thomas Gleixner [not found] ` <CACAVd4iRN7=eq_B1+Yb-xcspU-Sg1dmMo_=VtLXXVPkjN1hY5Q@mail.gmail.com> 2019-08-19 18:29 ` Thomas Gleixner [not found] ` <CACAVd4jAJ5QcOH=q=Q9kAz20X4_nAc7=vVU_gPWTS1UuiGK-fg@mail.gmail.com> 2019-08-20 8:49 ` Thomas Gleixner 2019-08-20 9:42 ` Arul Jeniston 2019-09-05 8:48 ` Arul Jeniston 2019-09-05 15:34 ` Thomas Gleixner 2019-09-06 16:36 ` Arul Jeniston 2019-09-07 14:38 ` Thomas Gleixner 2019-11-05 5:01 ` Arul Jeniston 2019-11-05 10:01 ` Thomas Gleixner 2019-11-06 3:38 ` Arul Jeniston
Reply instructions: You may reply publically 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=alpine.DEB.2.21.1908162255400.1923@nanos.tec.linutronix.de \ --to=tglx@linutronix.de \ --cc=arul.jeniston@gmail.com \ --cc=arul_mc@dell.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=viro@zeniv.linux.org.uk \ /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
Linux-Fsdevel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \ linux-fsdevel@vger.kernel.org public-inbox-index linux-fsdevel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git