linux-kernel - Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later

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:	Thu, 13 Mar 2014 09:12:48 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	joeyli <jlee@...e.com>
cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Julian Wollrath <jwollrath@....de>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	John Stultz <john.stultz@...aro.org>, Ted Ts'o <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later

On Thu, 13 Mar 2014, joeyli wrote:
> 於 三，2014-03-12 於 20:59 -0700，H. Peter Anvin 提到：
> > On 03/12/2014 08:55 PM, joeyli wrote:
> > > 
> > > So do not care "CMOS RTC Not Present", if TAD is present then we use it
> > > instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
> > > 
> > 
> > Why would we use *both*!?  How would that possibly make sense?
> > 
> > 	-hpa
> > 
> 
> Yes, it does not make sense for using both.
> 
> I switched the code in get_rtc_time() set_rtc_time() to TAD when it
> present, just make sure I'm on the right path.

No, you're not. get/set_rtc_time() is a complete trainwreck and as I
said before it should move into the rtc subsystem.

There is no reason at all to keep that stuff in the arch specific
code. It's there for historical reasons and that does not justify to
add more mess to it.

So the right thing to do is:

 1) Add eventually missing functionality to the RTC subsystem  

 2) Move the arch specific cmos stuff to the rtc subsystem as proper
    drivers 

 3) Add TAD there after #2 has been completed.

Any attempt to add TAD to arch/x86 is NACKed unconditionally.

Thanks,

	tglx