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  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:	Sat, 1 Nov 2008 09:29:05 -0700
From:	Arjan van de Ven <>
To:	Alan Stern <>
Cc:	Andrew Morton <>,
	Ingo Molnar <>,
	Linus Torvalds <>,
	Kernel development list <>
Subject: Re: (BUG?) round_jiffies() is non-monotonic on SMP

On Sat, 1 Nov 2008 12:14:41 -0400 (EDT)
Alan Stern <> wrote:

> Is it generally recognized that round_jiffies() can be non-monotonic
> on SMP systems?  By this, I mean that if cpu-a and cpu-b respectively
> do:
> 	ra = round_jiffies(ja);
> 		and
> 	rb = round_jiffies(jb);
> then the ordering of ra and rb can be opposite the ordering of ja and 
> jb.

round_jiffies() tends to be used (and is designed to be used) for cases
where you don't really care when exactly timers will fire... including
the order against other such timers.

> If this is known, is it regarded as a potential problem?  It certainly
> seems likely that some code somewhere depends on timeouts expiring in
> the correct order.

I don't think timeouts EVER have that guarantee between different cpus;
even if you don't round the timeouts.
After all, your CPU A can be in some delay loop with irqs off for
longer than the delta was, and boom.. the timers fire in different
If we ever have such ordering requirements in the kernel that
don't handle this... they're a bug...

> Alan Stern
> P.S.: As a related matter, it seems very odd that we don't have a 
> round_jiffies_up() routine.  Surely there are plenty of places where
> it doesn't matter if an event is a little late but where the event
> must not be early.  (I know two such places offhand.)  Any objection
> to having one added?

no objection per se, but I would almost argue we should convert such
places to range timers....
that way the kernel can, rather an aligning them, group them with other

Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists