From: Arul Jeniston <arul.jeniston@gmail.com> To: Thomas Gleixner <tglx@linutronix.de> 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, 6 Sep 2019 22:06:39 +0530 Message-ID: <CACAVd4hS1i--fxWaarXP2psagW-JmBoLAJRrfu9gkRc49Ja4pg@mail.gmail.com> (raw) In-Reply-To: <alpine.DEB.2.21.1909051707150.1902@nanos.tec.linutronix.de> Hi tglx, >Changing the return value to 1 would be just a cosmetic workaround. Agreed. Returning 1 is incorrect as It causes the next read() to return before the interval time passed. >So I rather change the documentation (this applies only to CLOCK_REALTIME >and CLOCK_REALTIME_ALARM) and explain the rationale. When timerfd_read() returns 0, hrtimer_forward() doesn't change expiry time, So, instead of modifying the man page, can we call timerfd_read() functionality once again from kernel. For example:- timerfd_read_wrapper() { do { ret = timerfd_read(...); } while (ret == 0); } Let us know whether you see any problem in handling this race in kernel. Regards, Arul On Thu, Sep 5, 2019 at 9:04 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > Arul, > > On Thu, 5 Sep 2019, Arul Jeniston wrote: > > When we adjust the date setting using date command we observed > > 'timerfd_read()' on CLOCK_REALTIME (TFD_TIMER_ABSTIME flag is set) > > returns 0. > > we don't see any hardware influence here and we are able to recreate > > it consistently. Is it expected? if yes, isn't it something to be > > documented in timerfd read() man page? > > It's expected, yes. Simply because it hits the following condition: > > armtimer(T1) > > settime(T1 + X) --> causes timer to fire > > wakeup reader > settime(T0) > > read number of intervals: 0 > > i.e. timer did not expire > > Changing the return value to 1 would be just a cosmetic workaround. We > could also jump back and wait again. But that's all not consistent because > > armtimer(T1) > > settime(T1 + X) --> causes timer to fire > > wakeup reader > > read number of intervals: 1 > settime(T0) > > user space reads time and figures that > the returned tick is bogus. > > So I rather change the documentation (this applies only to CLOCK_REALTIME > and CLOCK_REALTIME_ALARM) and explain the rationale. > > For applications which care about notifications when the time was set, > timerfd_settime() provides TFD_TIMER_CANCEL_ON_SET which causes the timer > to be canceled when time is set and returns -ECANCELED from the > read. That's unambiguous. > > 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 [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 [this message] 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=CACAVd4hS1i--fxWaarXP2psagW-JmBoLAJRrfu9gkRc49Ja4pg@mail.gmail.com \ --to=arul.jeniston@gmail.com \ --cc=arul_mc@dell.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=tglx@linutronix.de \ --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