linux-kernel - Re: [tip:timers/core] timerfd: Allow timers to be cancelled when clock was set

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

Message-ID: <1305109433.2914.208.camel@laptop>
Date:	Wed, 11 May 2011 12:23:53 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
	kay.sievers@...y.org, johnstul@...ibm.com, davidel@...ilserver.org,
	virtuoso@...nd.org, tglx@...utronix.de, chris.friesen@...band.com,
	kirill@...temov.name
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:timers/core] timerfd: Allow timers to be cancelled when
 clock was set

On Mon, 2011-05-02 at 19:44 +0000, tip-bot for Thomas Gleixner wrote:
> Commit-ID:  99ee5315dac6211e972fa3f23bcc9a0343ff58c4
> Gitweb:     http://git.kernel.org/tip/99ee5315dac6211e972fa3f23bcc9a0343ff58c4
> Author:     Thomas Gleixner <tglx@...utronix.de>
> AuthorDate: Wed, 27 Apr 2011 14:16:42 +0200
> Committer:  Thomas Gleixner <tglx@...utronix.de>
> CommitDate: Mon, 2 May 2011 21:39:15 +0200
> 
> timerfd: Allow timers to be cancelled when clock was set
> 
> Some applications must be aware of clock realtime being set
> backward. A simple example is a clock applet which arms a timer for
> the next minute display. If clock realtime is set backward then the
> applet displays a stale time for the amount of time which the clock
> was set backwards. Due to that applications poll the time because we
> don't have an interface.

Shouldn't that clock applet use CLOCK_MONOTONIC for the timer anyway?

Furthermore, weren't there patches to provide clkadjust notifiers? In
which case we can have the app woken up and it can fiddle its own
timers.

> Extend the timerfd interface by adding a flag which puts the timer
> onto a different internal realtime clock. All timers on this clock are
> expired whenever the clock was set.

I don't much like adding random clocks like that, the extra timer base
makes many timer operations more expensive, and I really don't see this
being worth it :/

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