linux-kernel - Re: 2.6.26, PAT and AMD family 6

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:	Wed, 7 May 2008 23:41:04 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Rene Herman <rene.herman@...access.nl>
cc:	Adrian Bunk <bunk@...nel.org>, Yinghai Lu <yhlu.kernel@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel <linux-kernel@...r.kernel.org>, hpa@...or.com,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	Pavel Machek <pavel@...e.cz>
Subject: Re: 2.6.26, PAT and AMD family 6

On Wed, 7 May 2008, Rene Herman wrote:
> On 07-05-08 22:52, Thomas Gleixner wrote:
> 
> > > And why do we need this clear_cpu_cap(c, X86_FEATURE_PAT) and then manual
> > > setting of X86_FEATURE_PAT at all?
> > 
> > The reason is to make cpu_has_pat a useful check and to avoid checking
> > cpu vendors, families and models inside of the PAT code. That's a good
> > thing actually, because the PAT code only cares about that cpu_has_pat
> > flag.
> > 
> > Clearing it in the cpuinfo is just a cosmetic side effect which does
> > no harm at all.
> 
> Oh yes, it does. It makes people unaware that their CPUs _should_ be
> supporting PAT. The thing's not called /proc/kernelinfo for a reason.

it's named /proc/cpuinfo and this unawareness of the until now not
utilized PAT feature is the least of our worries vs. PAT

> > > And this patch (by the author of the code himself) is the first time where
> > > it breaks.
> > 
> > Very interesting analysis. What broke ? This CPU was never in the set
> > of supported ones at all.
> 
> You misunderstood. Yinghai's patch only changed one of the code sites
> and not the others, which (if I understood right) is the breakage
> Adrian was reffering to.

I know exactly what he was referring to. So what's the problem ?

Yinghai missed to add it to the other place and he is hardly to blame
for that. This code is messy and thats not his fault. It will be
cleaned up, but that's not an simple taks to do. If you think you can
do it without breaking tons of systems, you're welcome.
 
> > Anyway, you are welcome to review x86 code - it can definitely use more
> > eyeballs, but please try to inform yourself about the topic or ask polite
> > questions before yelling at people who contribute in a very valuable way.
> 
> And would yelling at people how shuffle in code without (publicly at
> least) addressing one of your fellow arch maintainers objections

1) hpa asked a question http://lkml.org/lkml/2008/3/25/118
2) his question was answered http://lkml.org/lkml/2008/3/25/292
3) hpa did not object (no lkml ref, because there is none)

So what's your point ? Throwing factoids into a discussion is
not really helpful.

> and Pavel's review comments about code duplication without a single
> line of explanation/changelog do?

As I said before. The changelog is useless and Adrians point about
that is completely correct. 

Thanks,

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