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]

Message-ID: <alpine.DEB.2.02.1403042254550.18573@ionos.tec.linutronix.de>
Date:	Tue, 4 Mar 2014 23:11:21 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andy Lutomirski <luto@...capital.net>
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, 4 Mar 2014, Andy Lutomirski wrote:

> 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

There is a new patch series which adds deferrable support to all timer
related interfaces which have a flags field. And that's the only
sensible solution right now.

We do no add another random special case syscall for timerfd just
because timerfd is linux specific.

No, we want to support that stuff right now with the existing
interfaces as we have to revisit all of the timer related interfaces
in the near future anyway due to the Y2038 issue.

And your idea of per thread slack is completely bogus. If we want to
make the slack value usefull then it needs to be done per timer and
not per thread/process.

But we cannot do that right now as we cannot whip up severl dozen of
new syscalls just because we want to add slack/deferrable whatever
properties.

Once we agree on a solution to the Y2038 issue on 32bit with a unified
32/64 bit syscall interface which simply gets rid of the timespec/val
nonsense and takes a simple u64 nsec value we can add the slack
property to that without any further inconvenience.

Thanks,

	tglx

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