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: <4FBE4DB3.3070700@zytor.com>
Date:	Thu, 24 May 2012 08:03:15 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alex Shi <alex.shi@...el.com>
CC:	Arjan van de Ven <arjan@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Lutomirski <luto@....edu>,
	Jan Beulich <JBeulich@...e.com>, borislav.petkov@....com,
	arnd@...db.de, akinobu.mita@...il.com, eric.dumazet@...il.com,
	fweisbec@...il.com, rostedt@...dmis.org, hughd@...gle.com,
	jeremy@...p.org, len.brown@...el.com, tony.luck@...el.com,
	yongjie.ren@...el.com, kamezawa.hiroyu@...fujitsu.com,
	seto.hidetoshi@...fujitsu.com, penberg@...nel.org,
	yinghai@...nel.org, tglx@...utronix.de, akpm@...ux-foundation.org,
	ak@...ux.intel.com, avi@...hat.com, dhowells@...hat.com,
	mingo@...hat.com, riel@...hat.com, cpw@....com, steiner@....com,
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	"asit.k.mallick@...el.com" <asit.k.mallick@...el.com>
Subject: Re: [PATCH v7 8/8] x86/tlb: just do tlb flush on one of siblings
 of SMT

On 05/24/2012 07:32 AM, Alex Shi wrote:
>>
>> the TLB pool is shared as physical resource (dynamic or static, that
>> depends), but each tlb entry will be tagged for which of the two HT
>> pairs it's for, and on a logical level, they are completely separate as
>> a result (as they should be)
> 
> But, why just flush part of SMT doesn't crash kernel on many benchmarks
> testing? Does it means flush tlb without PCID (doesn't enable in current
> kernel) will flush both of 'TLB pool'?
> 
> Oh, lots of questions of the TLB pool details. :) Could you like share
> the URL of related documents?
> 

Hang on here... there is a huge difference between what a particular CPU
implementation does and what is architecturally guaranteed.

Both wearing my Linux x86 maintainer hat, and wearing my Intel employee
hat, I want to categorically state that Linux cannot rely on behavior
that isn't architecturally guaranteed.  Unless we can get an
architectural guarantee that this elision is safe, it cannot go in.  It
doesn't work the other way -- the burden of proof is to prove that the
change is safe, not that the change cannot be proven unsafe.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ