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:	Fri, 14 Dec 2007 10:37:15 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jan Beulich <jbeulich@...ell.com>,
	Glauber de Oliveira Costa <glommer@...il.com>
Subject: Re: [PATCH 2/4] x86: unify pgtable*.h


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

> All x86 modes and architectures have very similar pagetable 
> structures: the page flags, the accessors for testing/setting them, 
> and the combinations of page flags used for kernel and usermode 
> mappings are all the same.  The main difference is between 32 and 
> 64-bit pagetable entries, with the latter supporting the NX bit.
> 
> The most significant difference between the modes/architectures is the 
> number of levels in the pagetable (4 for 64-bit, 3 for 32-bit/PAE, 2 
> for non-PAE 32-bit).  This accounts for the remaining code in the 
> various mode-specific headers.
> 
> I've tried to avoid changing formatting as much as possible, so that 
> the code motion is more obvious.  A subsequent patch will clean things 
> up in place.

the dreaded auto-qa - this patch fails to build:

 arch/x86/mm/init_32.c: In function 'mark_rodata_ro':
 arch/x86/mm/init_32.c:811: error: 'PAGE_KERNEL_RX' undeclared (first use in this function)
 arch/x86/mm/init_32.c:811: error: (Each undeclared identifier is reported only once
 arch/x86/mm/init_32.c:811: error: for each function it appears in.)
 make[1]: *** [arch/x86/mm/init_32.o] Error 1

config attached. I'll skip this series of your patches for now. I'd 
expect this to be one of the hardest areas to unify - it's one of the 
areas with the largest amount of arbitrary deviations between 32-bit and 
64-bit and these include files permeate everything.

( In case you are thinking about approaching this differently, i'd 
  suggest a strategy that doesnt just try to unify the whole kit at once 
  but does it with very small steps where each step is trivially 
  verifyable. 50 small patches are generally a lot easier to create than 
  5 big patches. [ Of course if you can do 5 perfect patches that's just 
  as good :-) ] )

	Ingo

View attachment "config" of type "text/plain" (44818 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ