linux-kernel - Re: timer_settime() and ECANCELED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Apr 2020 14:16:22 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        linux-man <linux-man@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>, arul.jeniston@...il.com,
        "devi R.K" <devi.feb27@...il.com>,
        Marc Lehmann <debian-reportbug@...n9.de>,
        John Stultz <john.stultz@...aro.org>,
        Andrei Vagin <avagin@...il.com>
Subject: Re: timer_settime() and ECANCELED

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)