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
| ||
|
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/
Powered by blists - more mailing lists