linux-kernel - CLOCK_TICK_RATE, was: Re: [PATCH V4 3/4] ARM: Xilinx: base header files and assembly macros

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: <201102212208.10231.arnd@arndb.de>
Date:	Mon, 21 Feb 2011 22:08:10 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	"Russell King - ARM Linux" <linux@....linux.org.uk>
Cc:	John Linn <John.Linn@...inx.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	catalin.marinas@....com, glikely@...retlab.ca, jamie@...ieiles.com,
	linux-arch@...r.kernel.org
Subject: CLOCK_TICK_RATE, was: Re: [PATCH V4 3/4] ARM: Xilinx: base header files and assembly macros

On Monday 21 February 2011, Russell King - ARM Linux wrote:
> Eg, LOW_RES_NSEC is exported to userspace via the posix clocks interface.
> 
> NSEC_PER_SEC and TICK_NSEC are used for cmos clock updates, so probably
> don't matter too much there.  TICK_NSEC is also used by the scheduler,
> time conversions (timespec/timeval to/from jiffies) and profiling code.
> 
> NSEC_PER_JIFFY is used by the jiffy clocksource code, which only matters
> if you don't have your own clocksource.
> 
> So, I feel very uneasy about saying that CLOCK_TICK_RATE doesn't matter
> anymore given all the places which reference something that's derived
> from it.

All the calculations based off of CLOCK_TICK_RATE are derived from ACTHZ,
which is either the correct value based on the underlying HW timer tick,
or slightly off, when either the HW tick or the value of CLOCK_TICK_RATE
is not a true multiple of HZ.

In fact, I'm pretty sure that it's off on a lot of machines:

arch/frv/include/asm/timex.h:#define CLOCK_TICK_RATE            1193180 /* Underlying HZ */
arch/m68k/include/asm/timex.h:#define CLOCK_TICK_RATE   1193180 /* Underlying HZ */
arch/mips/include/asm/timex.h:#define CLOCK_TICK_RATE 1193182
arch/parisc/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
arch/s390/include/asm/timex.h:#define CLOCK_TICK_RATE   1193180 /* Underlying HZ */
arch/sh/include/asm/timex.h:#define CLOCK_TICK_RATE             1193180
arch/x86/include/asm/timex.h:#define CLOCK_TICK_RATE            PIT_TICK_RATE
arch/xtensa/include/asm/timex.h:#define CLOCK_TICK_RATE         1193180 /* (everyone is using this value) */

None of these is actually using a PC-style PIT these days, the just copied the
definition blindly from old i386. I think a simple

#define ACTHZ (HZ << 8)

would fix more than it can break, and most likely nobody would ever notice
the difference. If we do that, CLOCK_TICK_RATE becomes unused.

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