linux-kernel - Re: [tip:x86/idle] x86, hotplug: Move WBINVD back outside the play

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:	Mon, 20 Sep 2010 11:20:31 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Venkatesh Pallipadi <venki@...gle.com>
CC:	mingo@...hat.com, linux-kernel@...r.kernel.org,
	asit.k.mallick@...el.com, arjan@...ux.kernel.org,
	a.p.zijlstra@...llo.hl, lenb@...nel.org, tglx@...utronix.de,
	hpa@...ux.intel.com, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/idle] x86, hotplug: Move WBINVD back outside the play_dead
 loop

On 09/17/2010 05:48 PM, Venkatesh Pallipadi wrote:
>>
>> +       wbinvd();
>> +
>>        while (1) {
>> -               mb();
>> -               wbinvd();
>>                __monitor(&current_thread_info()->flags, 0, 0);
>>                mb();
> 
> 
> Just one observation. There are some CPUs with errata that need
> clflush before monitor. So, if that CPU wakesup spuriously it may have
> problem reentering idle. Not sure whether that will be a problem as
> that errata also depended on read happening on the flag. May be its
> better to do monitor (0, 0, 0).
> 

It seems the easy way to deal with that would be to just add clflush
before monitor... it is *probably* redundant, but it should be safe to
do. It means depending on X86_FEATURE_CLFLUSH as well as
X86_FEATURE_MWAIT, but I don't think there is any x86 processor which
has MWAIT and not CLFLUSH, and I highly doubt there ever will be.

Does anyone see any downside?

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