linux-kernel - Re: [PATCH 0/5] x86: another attempt at x86 pagetable unification

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:	Thu, 20 Dec 2007 10:49:40 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, Andi Kleen <ak@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Glauber de Oliveira Costa <glommer@...il.com>,
	Jan Beulich <jbeulich@...ell.com>
Subject: Re: [PATCH 0/5] x86: another attempt at x86 pagetable unification

* Jeremy Fitzhardinge <jeremy@...p.org> wrote:

> Here's another round of the pagetable unification patches.  I've done 
> a few dozen rounds of randconfig builds on both 32- and 64-bit, so I 
> hope that will prevent compile problems in your test environment.
> 
> I've also boot-tested 64-bit and 32-bit PAE/non-PAE configs (both 
> paravirt and non-paravirt).

i've done a dozen random tests too and it's looking good so far. Nice 
work!

pgtable_32.h and pgtable_64.h still look a tiny bit messy from the 
include file dependencies POV. For example pgtable_32.h:

 #include <asm/processor.h>
 #include <asm/fixmap.h>
 #include <linux/threads.h>
 #include <asm/paravirt.h>

 #include <linux/bitops.h>
 #include <linux/slab.h>
 #include <linux/list.h>
 #include <linux/spinlock.h>

that asm/paravirt.h include is already present in pgtable.h, in a 
somewhat quirky way:

#ifdef CONFIG_PARAVIRT
#include <asm/paravirt.h>
#else  /* !CONFIG_PARAVIRT */

also, most of the:

  scripts/checkpatch.pl --file include/asm-x86/pgtable*.h

complaints are real ones and should be fixed.

would you be interested in cleaning up that stuff once and forever? It 
would be a fine approach if you just tried to quickly push for a "high 
quality" end result in a series of patches and sent that series to me, 
without having tested it fully through - i can figure out whatever build 
breakages and dependencies there still are. So there would be no 
expectation of getting such a cleanup series right in the first (or 
second, or third) attempt, this is spaghetti code that has been 
accumulated up for years. The important thing would be to be careful to 
not introduce runtime breakages accidentally - build breakages due to 
some include file dependency we can sort out just fine. Hm?

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