linux-kernel - Re: [PATCHv6 0/7] system time changes notification

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:	Fri, 12 Nov 2010 14:30:44 +0200
From:	Alexander Shishkin <virtuoso@...nd.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Valdis.Kletnieks@...edu, linux-kernel@...r.kernel.org,
	John Stultz <johnstul@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Kay Sievers <kay.sievers@...y.org>, Greg KH <gregkh@...e.de>,
	Chris Friesen <chris.friesen@...band.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>
Subject: Re: [PATCHv6 0/7] system time changes notification

On Thu, Nov 11, 2010 at 10:16:03PM +0100, Thomas Gleixner wrote:
> B1;2401;0cOn Thu, 11 Nov 2010, Alexander Shishkin wrote:
> 
> > On Thu, Nov 11, 2010 at 03:28:13PM -0500, Valdis.Kletnieks@...edu wrote:
> > > On Thu, 11 Nov 2010 21:29:55 +0200, Alexander Shishkin said:
> > > 
> > > > Consider we want stuff like "wakeup every day at 3pm", the next wakeup
> > > > might be earlier than the timer we calculated last time, on system
> > > > time changes. We need to re-calculate it. This is necessary for all
> > > > repeating events.
> > > > 
> > > > Say we want to wakeup at 3pm, now it's 4pm, so we schedule it in 23
> > > > hours. Now the system time changes to 2pm, and we would expect to
> > > > wakeup in one hour, but we take 25.
> > > 
> > > Sorry, I tuned in late here...
> > > 
> > > So the plan is that if you're not using this new interface, it will go off at
> > > the same absolute offset (23 hours after timer was set), but if you're using
> > > this interface, your timer event gets interrupted, you get woken up (say)
> > > 15 hours into your 23, and it's your job to decide if you need to set a
> > > new timer for the remaining 6, 7, 8 hours or some other number?
> > 
> > Yes. This interface doesn't deal with timers, it only provides notifications.
> 
> The notification itself is pointless unless your application is
> dealing with timers which need to be adjusted the one way or the
> other.

Not quite. There are two use cases that I know of that need this notification
but don't use timers like that. One was described by Chris Friesen in the
comments to the first version of this patchset [1]. The other one was
described by me in the same thread [2]. They could, of course start using
timers specifically to get this notification, but I'm not sure if it doesn't
abuse the whole idea of timers.

> That said, I'm still not convinced that this usecase justifies a new
> systemcall.

Well, initially it was a sysfs interface (an arguably ugly one, though).

> 1) We can make timers wake up when a clock change happens

Isn't there a race so that if two clock changes happen in quick succession,
the user might lose the second one while he restarts the timer?

> 2) Can't we use existing notification stuff like uevents or such ?

I thought about that in the beginning but uevents indeed seem too heavy
for this sort of notification, especially compared to eventfds.

[1] http://lkml.org/lkml/2010/8/4/383
[2] http://lkml.org/lkml/2010/8/5/192

Regards,
--
Alex
--
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/