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.0801221119180.3199@apollo.tec.linutronix.de>
Date:	Tue, 22 Jan 2008 14:12:32 +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 Mon, 21 Jan 2008, Andi Kleen wrote:
> > It's a first shot so it might not yet be perfect - although so far it 
> > looks good in testing on 4-5 testsystems here, on mixed 64-bit and 
> > 32-bit boxes. Doing it this way was a pretty straightforward process, it 
> > took less than an hour - and the end result feels much better in terms 
> > of maintainability.
> 
> You still kept Venki's redundant 32bit reference count change for 32bit.
> The code handled that already by doing reserved bits check.

Hmm. Which patch are you referring to ? There is no patch from Venki
in x86.git which touches the pageattr code.

> IMHO it would have been cleaner to also do that for the 64bit version
> instead of abusing the reference counting for this (like my
> "CPA Handle 4K split pages at boot on 64bit" patch did). 

I don't understand what you mean. The "CPA Handle 4K split pages at
boot on 64bit" patch is in x86.git:

http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-x86.git;a=commit;h=360b371f73b96c400c6a8fc19ea334d083c65c92

Please clarify.

> > I left the clflush feature bits out for now - fixes and cleanups go 
> > first. We first need to see whether this is robust enough before making 
> > other changes to c_p_a(). There's enough on the arch/x86 plate for 
> > v2.6.25 already - we can try the clflush optimizations in v2.6.26. 
> > (since there's no high-freq in-kernel user of the c_p_a() API at the 
> > moment, there's no pressing need for this either.)
> 
> Ok I'll redo it. Thank you for your support.
> 
> Probably in larger chunks now though -- with your somewhat
> random patching applying methology larger small grained series are just too 
> painful for me.

Please keep them fine-grained and keep fixes separate and prior to
features.

> First priority will be gbpages on top of it.

First priority is getting CPA and PAT consolidated before we put new
functionality on top of it. This implies a possible unification of the
32 and 64 bit code as well. There is no real good reason to have
different implementations for those.

> I would appreciate if you could either prevent or warn against further
> wide scale changes on these files before .26 then -- otherwise I'll have
> again play catch up with a relatively large patchkit.

FYI, the consolidation of CPA and PAT is changing that code, so flux
is expected.

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/