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  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:	Fri, 03 Jan 2014 16:18:27 -0800
From:	John Stultz <>
To:	Alexey Perevalov <>
Subject: Re: [PATCH 0/3] Deferrable timers support for timerfd API

On 01/03/2014 09:45 AM, Alexey Perevalov wrote:
> On 01/03/2014 03:17 AM, John Stultz wrote:
>> On 01/02/2014 10:30 AM, Alexey Perevalov wrote:
>>> This version introduces new clockid (CLOCK_DEFERRABLE) , for
>>> timerfd_create, instead of
>>> new flag (TFD_TIMER_DEFERRABLE) for timerfd_settime introduced in
>>> previous version.
>> So why did you make this change?
>> thanks
>> -john
> I looked at alarm timers and found approach of making timer behavior
> persistent per file descriptor is better than
> changeable by timerfd_settime. I think "end user wake up from suspend"
> and "don't wake up in idle" is the same thing on the same abstraction
> level.
> Yes Anton's previous  patches worked with CLOCK_MONOTONIC only and I
> didn't intend to use it with CLOCK_REALTIME, cause it's hard to me to
> find such use case.
> Another way - it's stay as was Anton's patch, I mean as flag for the
> timerfd_settime, but in original patch set both hrtimer and deferrable
> timers initialized in timerfd_create, I think it's not needed. Also
> ability to change timer behavior looks not good if you couldn't change
> alarm timer behavior, not unified API.

So while the alarm timers are a reasonable precedent, I think they were
introduced prior to the timerfd interface, so it seemed at the time
having new clockids for the functionality was required to work with the
existing syscalls that use the clockid (Though in retrospect, I question
if it would have been better to use timer flags to introduce the alarm
functionality rather then introducing it via a clockid, as it would
simplify the clockid definitions).

Now that we have the timerfd interface, and if this functionality is
really limited to the timerfds, then we may want to consider what might
be, at least to me, the cleaner approach of using the flag.

Either way, I'd like to make sure we have a sound rational. My worry is
that deferrable timers would be desired on more then just
CLOCK_MONOTONIC, so we could quite likely end up with quite a few new

> If I'm right, only high resolution timer could be REALTIME, and there
> is no deferrable behavior for hrtimer only for timer_list.
I'm not sure I understood this part. Could you explain further?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists