linux-kernel - Re: [PATCH 2/4] x86: unify pgtable*.h

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] [day] [month] [year] [list]

Message-ID: <4762A640.2050600@goop.org>
Date:	Fri, 14 Dec 2007 07:50:24 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
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

Ingo Molnar wrote:
> * 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
>   

Sigh.  Shouldn't be too hard to deal with.

> 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.
>   

Yeah, it's been great fun :(.  On the other hand, I think its getting
there; the interactions between the various headers is getting more
comprehensible, and moving to a consistent use of inline functions
rather than a mixture of macros and inlines is making things more
deterministic.

> ( 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 :-) ] )
>   

Yeah, I tried doing it in smaller pieces, but its fairly difficult just
because its all so inter-tangled.  But I think its close now.

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