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: <alpine.LFD.1.10.0809012015160.12958@nehalem.linux-foundation.org>
Date:	Mon, 1 Sep 2008 20:18:47 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Larry Finger <Larry.Finger@...inger.net>,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alok Kataria <akataria@...are.com>,
	Michael Buesch <mb@...sch.de>
Subject: Re: Regression in 2.6.27 caused by commit bfc0f59



On Tue, 2 Sep 2008, Thomas Gleixner wrote:
> 
> We had the same problem versus the local APIC timer calibration, which
> had basically the same algorithm as the TSC one and we changed it to
> look at the PMTimer as well in the days where we debugged the initial
> wreckage caused by the nohz/highres changes.

Hmm.

So then how would you discover when it's reliable and when it's not? Just 
hardcode it for certain machines?

One alternative might be to do the same "detect if it's SMM code by seeing 
how long the read takes" for the PIT reads themselves. Right now the code 
does it for the HPET timer read and for the PM_TIMER reads, but _not_ for 
the PIT status register reads.

> How do you prevent the SMM brain damage, when it hits 3 times in a row ? 

Well, the biggest problem is actually _detection_.

We have three different timers, and they all have their own problems. How 
do you reliably detect which one to use? The PM_TIMER clearly is _not_ 
always the answer here, but the code just assumes it is!

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ