linux-kernel - Re: CPA boot crash (was: [PATCH] [0/36] Great change_page

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.00.0801221623210.3199@apollo.tec.linutronix.de>
Date:	Wed, 23 Jan 2008 01:35:55 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andi Kleen <ak@...e.de>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	jbeulich@...ell.com, venkatesh.pallipadi@...el.com,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: CPA boot crash (was: [PATCH] [0/36] Great change_page_attr patch
 series v3)

On Tue, 22 Jan 2008, Andi Kleen wrote:
> According to you and Ingo "the global perspective" is to get
> simple stuff first in. But in this case you're doing the complicated
> (and worse the unfinished) stuff first which seems to be against
> your own principles.

No, the global perspective is to get a stable and reliable system,
which allows us to do new features like gbpages, PAT and whatever
comes up next in a clean way.

Your patches just shove another extra into the existing code base
without doing any consolidation work and without any consideration of
problems we need to urgently solve in this area.

Your only care is to get stuff merged which is interesting for you. I
can understand that, but it should be entirely clear to you as an
engineer that ignoring the existing problems and adding more (even
simple) stuff makes it more complex to consolidate and is nothing else
than bad engineering.

PAT is high on the requirements list, not because it's not complex (it
definitely is), but simply because Linux has a years long of backlog
(it's the only modern OS on the planet still not using PAT) and
hardware makers are stepping beyond the limits of MTRRs. There is an
increasing number of systems which don't work under Linux properly due
to the MTRR limitations, but work perfectly fine with other
OSs. Should we ignore that ?

While PAT is a 10 years old hardware feature, gbpages is a feature for
a brand new chip, which is not even available to mere mortals in a
useable form. And there is no real problem with not having gbpages for
some time. So where is the pressure to get that in? Just because it
can be done and happens to work on some test machine?

PAT patches have been around for years and nothing happened - while
the first time gbpages were submitted was 19 days ago by you.

Of all pending features, PAT has a priority simply because it
affects users. The lack of gbpages does not. We are not going to rush
PAT in before it is stable, but we hold everything off which
interferes with getting it to that point.

Please stop arguing around with the subtle undertone of us having no
clue about the topics. We looked into the whole set of pending issues,
including your gbpages patchset and we well understand the
implications. It is quite clear that we need to fix the underlying
system _before_ we add more things to it. That applies to PAT, CPA and
gbpages in the same way.

In the end all of those features will benefit from a consolidated
implementation.

It's up to you whether you help to get there sooner or just sit back
and argue in circles until others have done the hard work and you can
add gbpages.

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/