linux-kernel - Re: [GIT PULL] scheduler fixes

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.2.01.0909301743150.6996@localhost.localdomain>
Date:	Wed, 30 Sep 2009 17:57:27 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <johnstul@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [GIT PULL] scheduler fixes

On Wed, 30 Sep 2009, Linus Torvalds wrote:
> 
> Pulled. I'd also like to see something that actually fails gracefully on 
> cmpxchg() of an unsupported size, though. The silent failure still annoys 
> me.

Oh, and we probably should try to avoid the 'alternates()' code when we 
can statically determine that cmpxchg8b is fine. We already have that 
CONFIG_x86_CMPXCHG64 (enabled by PAE support), and we could easily also 
enable it for some of the CPU cases.

[ If I recall correctly, cmpxchg8b support detection was something that 
  was totally messed up in WNT, and I have this memory of TMTA _not_ 
  claiming to support CX8 in the cpuid bits, but happily supporting the 
  instruction itself - because otherwise WNT would blue-screen on boot or 
  something silly like that.

  As a result, the patch below only adds CMPXCHG8B for the obvious Intel 
  CPU's, not for others. There was something really messy about cmpxchg8b 
  and clone CPU's, but I'm not 100% sure about the details, so take this 
  patch with a pinch of salt, and some thinking ]

If we avoid that asm-alternative thing when we can assume the instruction 
exists, we'll generate less support crud, and we'll avoid the whole issue 
with that extra 'nop' for padding instruction sizes etc.

			Linus

---
 arch/x86/Kconfig.cpu |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 527519b..f2824fb 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -400,7 +400,7 @@ config X86_TSC

 config X86_CMPXCHG64
 	def_bool y
-	depends on X86_PAE || X86_64
+	depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MATOM

 # this should be set for all -march=.. options where the compiler
 # generates cmov.
@@ -412,6 +412,7 @@ config X86_MINIMUM_CPU_FAMILY
 	int
 	default "64" if X86_64
 	default "6" if X86_32 && X86_P6_NOP
+	default "5" if X86_32 && X86_CMPXCHG64
 	default "4" if X86_32 && (X86_XADD || X86_CMPXCHG || X86_BSWAP || X86_WP_WORKS_OK)
 	default "3"

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