linux-kernel - Re: [PATCH v2] x86: Quark: Add if/else to setup

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <542A150E.5070406@nexus-software.ie>
Date:	Tue, 30 Sep 2014 03:27:26 +0100
From:	Bryan O'Donoghue <pure.logic@...us-software.ie>
To:	"Ong, Boon Leong" <boon.leong.ong@...el.com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>
CC:	"hpa@...or.com" <hpa@...or.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"davej@...hat.com" <davej@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] x86: Quark: Add if/else to setup_arch for Quark TLB
 bug

On 30/09/14 02:46, Ong, Boon Leong wrote:
>>
>> My view is that the CR3 load should have flushed the TLB in it's entirety.
>>
>> Ong Boong Leong said that a discussion he had which included HPA concluded
>> with a flush of the TLB being required after the CR3 reload.
>
> The proposed patch was discussed in April and after much thought into this,
> I will suggest that as long as the commentary properly captured down why
> __flush_tlb() is **NOT** needed because load_cr3() will have the same effect.

Agree.

>>
>> The current code
>>
>> My preference is
>>
>> 1. Just comment the code as is to explain why it works for Quark.
>>
>> If that's not good enough for people then
>>
>> 2. if/else the flow so that Quark does __flush_tlb() and the rest of the world
>> does a __flush_tlb_all()
> Bryan, just drop this proposal from my submission even though __flush_tlb() is
> more obvious in what is supposed to do and does not consume any significant cpu-time.

Very good. I've a new patchset ready to report cache size based on the 
callbacks that Ingo and Dave suggested - found a bug too - so I'll 
submit those changes as one.

1. Comment
2. Reporting of cache size
3. Bugfix to the code path for legacy_cache_size => currently broken for 
{PIII Tualatin, a bunch of AMDs, and some VIAs too by the looks of it}


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