linux-kernel - Re: [PATCH v4 5/6] timerfd: Add support for deferrable timers

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]

Date:	Tue, 4 Mar 2014 13:53:03 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Alexey Perevalov <a.perevalov@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Anton Vorontsov <anton@...msg.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	cw00.choi@...sung.com, Andrew Morton <akpm@...ux-foundation.org>,
	Anton Vorontsov <anton.vorontsov@...aro.org>
Subject: Re: [PATCH v4 5/6] timerfd: Add support for deferrable timers

On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Tue, 25 Feb 2014, Andy Lutomirski wrote:
>> On the other hand, if you added a fancier version of timerfd_settime
>> that could explicitly set the slack value (or, equivalently, the
>> earliest and latest allowable times), that could be quite useful.
>>
>> It's often bugged me that timer slack is per-process.
>
> That's a totally different issue. There is a world aside of timerfd
> timers.

This is a patch to add deferrable support *to timerfd*.  I'm asking
why this is a useful feature to add.  Some day (maybe soon -- systemd
is doing something awful here) people will want choices of slack
values other than the per-process value and infinity.  Why not just do
that and skip this intermediate API that will have to be supported
forever?

I admit that I don't really understand the difference between hrtimers
and the other kind of timer internally, but I don't see why this
should have any effect at all of the userspace API.  The kernel
supports slack, slack is strictly more useful than "deferrable", so
let's just expose it properly to userspace.

--Andy
--
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/