linux-kernel - Re: [PATCH] tsc_khz= boot option to avoid TSC calibration variance

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:	Wed, 13 May 2009 00:42:50 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	john stultz <johnstul@...ibm.com>
cc:	Ulrich Windl <ulrich.windl@...uni-regensburg.de>,
	linux-kernel@...r.kernel.org, Clark Williams <williams@...hat.com>,
	zippel@...ux-m68k.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] tsc_khz= boot option to avoid TSC calibration variance

On Tue, 12 May 2009, john stultz wrote:
> > stored or accumulated before. For the TSC calibaration one could build the average 
> > of previous calibration values (if the value jumps between different numbers).
> > That would require a sysctl (or equivalent) interface however.
> 
> I still feel that a sysctrl or /sys/ interface for this sort of thing is
> overkill. It creates yet another interface we have to manage, and really
> doesn't improve the situation more then the boot option would.
> Additionally it would require quite a bit of work at the clocksource
> level to allow for re-calibration (currently we avoid this by
> disqualifying the TSC if it changes freq). 
> 
> That said, I've gotten very few positive comments from my patch, so I'm
> going to give it one more spin (to address Serge's point) and if folks
> are still feeling blah about it I'll stop pushing it.

I'm fine with the command line option, but I refuse to add some sys/
thingy which makes us add extra calibration stuff.

Honestly all this is just the futile attempt to fix the flaws of NTP
via (super)user interaction.

Darn, it can not be that hard to adjust the math to do what you think
it should do. I'm not an expert on that NTP stuff, but blindly
stuffing the last known value into the kernel and expect that the
calibration value did not change is nonsense.

You know the calibration value which created the last known parameters
and you want an extra interface to inject this last known calibration
value into the kernel instead of doing the math of adjusting the NTP
parameters according to the change of calibration values ?

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/