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]

Message-ID: <48222784.10506@keyaccess.nl>
Date:	Thu, 08 May 2008 00:04:52 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Thomas Gleixner <tglx@...utronix.de>
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 07-05-08 23:41, Thomas Gleixner wrote:

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

Exactly.

> and this unawareness of the until now not utilized PAT feature is the
> least of our worries vs. PAT

It's _my_ worry. I-the-user don't want my cpuinfo lying to me just
because if fits your-the-developer's codeflow better. Sheer insanity.

Getting philosophical tends to be a bad idea here but like always and
in this case; if you hide the world from people you disallow them from
improving it. It's that I _knew_ that my CPU should be supporting PAT
so that I could complain about it, but I'm your average LKML dwelling
datasheet collector.

Your feature may be very important and groovy to you, but to me it's
much more important that my cpuinfo doesn't lie to me. Please make it
not lie to me.

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

What on earth? Yes, it is. He added that code. The only thing that this complaint
is about is that his fix-patch added the family 6, model 7 to only _one_ instance
of that code that he himself added and not all three.

>> 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 HPA (and Molnar) then said in response to that answer:

http://lkml.org/lkml/2008/3/25/322

It's right there in response to your own link. It seems you originally missed
it, but how did you manage this time again?
 
>> 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. 

Pavel was full of it? 

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