linux-kernel - Re: [PATCH RFC] x86: hpet: Avoid the readback penalty

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] [day] [month] [year] [list]

Date:	Sat, 18 Sep 2010 14:43:06 +0100
From:	Nix <nix@...eri.org.uk>
To:	Damien Wyart <damien.wyart@...e.fr>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	Artur Skawina <art.08.09@...il.com>,
	John Drescher <drescherjm@...il.com>,
	Venkatesh Pallipadi <venki@...gle.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Borislav Petkov <borislav.petkov@....com>,
	Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [PATCH RFC] x86: hpet: Avoid the readback penalty

On 18 Sep 2010, Damien Wyart uttered the following:

> * Thomas Gleixner <tglx@...utronix.de> [2010-09-15 15:11]:
>> > x86: hpet: Work around hardware stupidity
>
>> After my brain recovered from yesterdays exposure with the x86 timer
>> horror, I came up with a different solution for this problem, which
>> avoids the readback of the compare register completely. It works
>> nicely on my affected ATI system, but needs some exposure to the other
>> machines.
>
> Comments for this different solution seemed fine, but it seems only the
> first one was commited into mainline and then stable. Is this intended?

I assumed he was letting people shake the bugs out rather than inflict
what is basically just a performance improvement on -stable. For the
record: no bugs here. I also know why one of my machines was unaffected,
and it provides even more confirmation that this bug is correctly
identified, as if we needed more. It's not using the HPET at all:

Clock Event Device: cs5535-clockevt

Every single machine I owned with an HPET was affected by this bug: they
all work perfectly well now.
--
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/