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] [day] [month] [year] [list]

Message-id: <52D2CDFA.9050501@samsung.com>
Date:	Sun, 12 Jan 2014 21:16:42 +0400
From:	Alexey Perevalov <a.perevalov@...sung.com>
To:	John Stultz <john.stultz@...aro.org>
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 01/10/2014 12:32 AM, John Stultz wrote:
> 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?
Posix timer doens't have cancel_list ability right now.
Do you want to add such ability?
With posix timer there is no problem of interference O_ flags,
and flag for posix timer might have the same value as 
TFD_TIMER_CANCEL_ON_SET,
and appropriate name.

Version of Anton's patches with flag based interface I'll send tomorrow.
But with little modification in overruns, I think evaluation
based on hrtimer for overrun is not proper way for deferrable timer, because
in most cases number of deferrable ticks is lesser.

> thanks
> -john
>


-- 
Best regards,
Alexey Perevalov
--
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/