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: <alpine.LFD.1.10.0805072341210.3318@apollo.tec.linutronix.de>
Date:	Wed, 7 May 2008 23:54:19 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Adrian Bunk <bunk@...nel.org>
cc:	Yinghai Lu <yhlu.kernel@...il.com>,
	Rene Herman <rene.herman@...access.nl>,
	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 Thu, 8 May 2008, Adrian Bunk wrote:
> On Wed, May 07, 2008 at 10:52:36PM +0200, Thomas Gleixner wrote:
> > We have a well identified set of CPUs which can handle PAT and we dont
> > want to open up a can of worms by unconditionally enabling it on any
> > piece of silicon which claims to support PAT. This was made clear from
> > the first submission of PAT.
> 
> But the commit description is empty.

Care to read, what I wrote futher down ?

"Yes, that's a valid complaint. The changelog is pretty useless."
 
> > Also there is no downside on these older systems. They are fine with
> > MTRRs and have been for years. We can revisit that once PAT support
> > has stabilized.
> 
> My comment was about:
> "please try attach patch to see if duron support PAT."

I know.
 
> That information is for sure available.

So you know where it is and you can confirm that it works fine ?

Pointers please. 

> > This feature and detection code is hard to clean up and definitely out
> > of the scope of this patch.
> 
> Did you even look at the commit we are discussing?
> 
> It ***adds*** exactly the same code at three different places.

Yes, I did. And it adds it for a fscking good reason. 

1) two times in common.c due to the existing detection logic mess
2) once in the 64 bit version

Again, this code is inherited and fragile mess, which can not be
changed at will.

> >...
> > > 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.
> 
> The patch in the email I answered to was broken since the author did 

"the author" has a name.

> fall into his own trap by patching only one copy of his duplicated code.

That's not a real good reason to yell at him.

Yinghai  wanted to help out and check with the reporter whether this CPU
works with PAT or not.

Yinghai made a mistake.

You come along and ride a crusade against him for that. Very helpful.

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/