linux-kernel - Re: [PATCH 0/3] Deferrable timers support for timerfd API

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]

Message-ID: <CALAqxLXvK0Ptob-6kXVXnHdpo4JfwzvKmd41SG77Uq0=yY=ZPg@mail.gmail.com>
Date:	Thu, 9 Jan 2014 12:32:58 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Alexey Perevalov <a.perevalov@...sung.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Anton Vorontsov <anton@...msg.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/3] Deferrable timers support for timerfd API

On Sun, Jan 5, 2014 at 11:33 AM, Alexey Perevalov
<a.perevalov@...sung.com> wrote:
> On 01/04/2014 04:18 AM, John Stultz wrote:
>>
>> 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).
>
> As I understood alarm and deferrability it's type of repetition (timer
> trigger condition),
> but REALTIME, BOOTTIME, MONOTONIC it's a type of time representation.
> Mixed it in one clockid, maybe it's a controversially. Which flags do you
> want to use, flags of timerfd_settime?

Well, my first reaction was just to suggest you create a new timer
flag (like TIMER_ABSTIME) TIMER_DEFER, which we could then consider
adapting as a new flag value for all the timer related code
(posix-timers, nanosleep, etc).

Then looking closer at the timerfd code, I see I wasn't aware there's
some additional constraints as the timerfd flags overlap with many of
the file O_ flags, and that the timerfd has its own TFD_TIMER_ABSTIME.
 I'm not quite sure I recall the context of that decision, so it might
be good to involve those who recall more of that history. So I'm not
sure which particular bit flag would be best to take there. Anton's
patch took (1<<2), so I'm guessing that's still ok.

Anyway, adding something like a TFD_TIMER_DEFER along with TIMER_DEFER
would seem to me like a reasonable approach.

Addtionally the TFD_CANCEL_ON_SET is interesting in that we don't have
a similar flag for the posix timers interfaces. Do you think there's
any value in looking into unifying that as well?

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/