Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 1 Apr 2020 14:16:22 +0300
From:   Cyrill Gorcunov <gorcunov@gmail.com>
To:     "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        linux-man <linux-man@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>, arul.jeniston@gmail.com,
        "devi R.K" <devi.feb27@gmail.com>,
        Marc Lehmann <debian-reportbug@plan9.de>,
        John Stultz <john.stultz@linaro.org>,
        Andrei Vagin <avagin@gmail.com>
Subject: Re: timer_settime() and ECANCELED
Message-ID: <20200401111622.GQ3197@uranus>
References: <CAKgNAkgiZna0yQzkdZQ92CJzjBcxX6eEu1cg24Oeu2pXRcSv8A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKgNAkgiZna0yQzkdZQ92CJzjBcxX6eEu1cg24Oeu2pXRcSv8A@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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)