Re: timer_settime() and ECANCELED

[Cyrill Gorcunov <gorcunov@gmail.com>]

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)