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:	Tue, 22 Jan 2008 15:06:00 +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:

> > First priority is getting CPA and PAT consolidated before we put new
> 
> PAT seems to be still quite unstable and frankly for me it is 
> unclear how long it will take to it become stable. It would
> not surprise me if it takes longer than the .26 merge window.

Definitely, if we change the code further without doing anything to
consolidate it in the first place. 

Have you even cared to look, why PAT is so ugly and fragile ? Simply
because it interferes/interacts with CPA and the page table code. So
adding further stuff to that area without considering the requirements
of PAT will make it worse.

> You're saying you want to delay an relatively simple and imho
> relatively mature feature like gbpages after that complicated and risky 
> feature PAT? Please take a look at the patches; they're really
> not very complicated.

It's not a question of complicated or not. Fact is, that PAT is
interfering with all this and any new feature will make it harder to
stabilize.

> That seems to me like against your own principles -- simple stuff
> first -- that you two harped on so extensively on earlier this thread.

Not at all. If the simple stuff makes it harder to do something else,
then it is not longer simple. Then it is simply in the way. 

If your patches are so simple, then they can be done on top of a
consolidated CPA/PAT easily.

> For me it would make much more sense to put the gbpages first
> than to delay them for PAT. I only didn't argue this strongly
> earlier because PAT was already rushed in (for me quite suprisingly) 
> and I didn't want to argue for dropping it.
>
> But now that it is gone again anyways delaying the gbpages for it again
> would be quite unfortunate from my perspective.

I can understand that, because it is in the way of your particular
interests, but we have to look at the global picture and not at the
personal preferences of you or anyone else.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ