linux-kernel - Re: [PATCH 1/1] Page Table cleanup patch

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]

Date:	Thu, 25 Jan 2007 11:17:22 +1100 (EST)
From:	Paul Cameron Davies <pauld@....unsw.EDU.AU>
To:	Nick Piggin <nickpiggin@...oo.com.au>
cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] Page Table cleanup patch

Hi Nick

On Wed, 24 Jan 2007, Nick Piggin wrote:

> Paul Davies wrote:
>> This patch is a proposed cleanup of the current page table organisation.
>> Such a cleanup would be a logical first step towards introducing at least
>> a partial clean page table interface, geared towards providing enhanced 
>> virtualization oportunities for x86.  It is also a common sense cleanup in 
>> its own right.
>>
>>  * Creates mlpt.c to hold the page table implementation currently held 
>> in memory.c.
>>  * Adjust Makefile  * Move implementation dependent page table code out of 
>> include/linux/mm.h into include/linux/mlpt-mm.h
>>  * Move implementation dependent page table code out of 
>> include/asm-generic/pgtable.h to include/asm-generic/pgtable-mlpt.h
>> 
>> mlpt stands from multi level page table.
>
> Hi Paul,
>
> I'm not sure that I see the point of this patch alone, as there is still
> all the mlpt implementation details in all the page table walkers. Or
> did you have a scheme to change implementations somehow just using the
> p*d_addr_next?

This patch alone doesn't acheive nearly enough.  Separating out as much
implementation (without tackling the walkers) would be a start though.
The MLPT appears to be intrinsic to the kernel owing to its open coding, 
and starting to isolate its implementation (even partially) is an 
important step towards destroying this misconception.

I strongly prefer not to go down the path of using a scheme to change 
implementations with p*d_addr_next.  I tried this kind of thing early on 
and it was horribly ugly.  There are far cleaner ways to do it.

Cheers

Paul Davies
-
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/