[PATCH RFP-V4 00/13] remap_file_pages protection support - 4th attempt

[Blaisorblade <blaisorblade@yahoo.it>]

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

Again, about 4 month since last time (for lack of time) I'm sending for final 
review and for inclusion into -mm protection support for remap_file_pages (in 
short "RFP prot support"), i.e. setting per-pte protections (beyond file 
offset) through this syscall.

Since last release, I've changed the PTE bits encoding I've used to avoid 
adding overhead in pte_present() - I don't remember complaints other than this 
one. UML support should follow in a short time.

Below there is the commentary I included last time, with some updates.
I've also attached the program I use for unit testing of the patch.

The patches themselves will only go to akpm, LKML and linux-mm, to avoid an 
invasion of your mailboxes :-)

After this batch of patches has been merged, I will be able to start further 
work basing on those - optimizations, restructuring and such, but the 
functionality is already present; since I had little time I decided to work 
on the basic set first, to avoid too many ports to newer releases.

== Notes ==

Arch-specific bits are provided for i386, x86_64 and UML, and for some other 
archs I have patches I will send, based on the ones which were in -mm when 
Ingo sent the first version of this work.

You shouldn't worry for the number of patches, most of them are very little.
I've last tested them in UML, i386 x86-64 against 2.6.18-rc3/rc4 (where 
_tested_ means compile, boot and unit-tested).

== How it works ==

Protections are set in the page tables when the page is loaded, are saved into 
the PTE when the page is swapped out and restored when the page is faulted 
back in.

Additionally, we modify the fault handler since the VMA protections aren't 
valid for PTE with modified protections.

Finally, we must also provide, for each arch, macros to store also the 
protections into the PTE; to make the kernel compile for any arch, I've added 
since last time dummy default macros to keep the same functionality.

== What is this for ==

The first idea is to use this for UML - it must create a lot of single page 
mappings, and managing them through separate VMAs is slow (in last discussion 
Ingo Molnar provided impressive numbers about this).

With a little additional change (to allow limited usage on MAP_PRIVATE 
readonly VMAs) it will be possible to use this also for shared objects guard 
pages on x86_64; guard pages for thread stacks can also be easily addressed; 
handling read/write private vmas (which was in Ulrich's wish list) was also 
maybe possible but there are limitations for that so I've left that totally 
apart.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade

[-- Attachment #2: fremap-test-complete.c.bz2 --]
[-- Type: application/x-bzip2, Size: 5510 bytes --]