On Wed, Apr 01, 2020 at 11:01:18AM +0200, Michael Kerrisk (man-pages) wrote:
> Hello Thomas, et al,
>
> Following on from our discussion of read() on a timerfd [1], I
> happened to remember a Debian bug report [2] that points out that
> timer_settime() can fail with the error ECANCELED, which is both
> surprising and odd (because despite the error, the timer does get
> updated).
>
> The relevant kernel code (I think, from your commit [3]) seems to be
> the following in timerfd_setup():
>
> if (texp != 0) {
> if (flags & TFD_TIMER_ABSTIME)
> texp = timens_ktime_to_host(clockid, texp);
> if (isalarm(ctx)) {
> if (flags & TFD_TIMER_ABSTIME)
> alarm_start(&ctx->t.alarm, texp);
> else
> alarm_start_relative(&ctx->t.alarm, texp);
> } else {
> hrtimer_start(&ctx->t.tmr, texp, htmode);
> }
>
> if (timerfd_canceled(ctx))
> return -ECANCELED;
> }
>
> Using a small test program [4] shows the behavior. The program loops,
> repeatedly calling timerfd_settime() (with a delay of a few seconds
> before each call). In another terminal window, enter the following
> command a few times:
>
> $ sudo date -s "5 seconds" # Add 5 secs to wall-clock time
>
> I see behavior as follows (the /sudo date -s "5 seconds"/ command was
> executed before loop iterations 0, 2, and 4):
Hi Michael, I can be wrong (since I didn't look into timerfd code
for long time) but I guess if we wanna preserve the timer value
we will have to lock timekeeper which is inacceptable. Thus looks
like this is a tradeoff in a sake of speed (not sure though, better
wait for Thomas reply)
