Blaisorblade wrote:
On Tuesday 02 May 2006 05:45, Nick Piggin wrote:
[email protected] wrote:
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.
I think I would rather this all just folded under VM_NONLINEAR rather than
having this extra MANYPROTS thing, no? (you're already doing that in one
direction).
That step is _temporary_ if the extra usages are accepted.
Can we try to get the whole design right from the start?
Also, I reported (changelog of patch 03/14) a definite API bug you get if you
don't distinguish VM_MANYPROTS from VM_NONLINEAR. I'm pasting it here because
that changelog is rather long:
"In fact, without this flag, we'd have indeed a regression with
remap_file_pages VS mprotect, on uniform nonlinear VMAs.
mprotect alters the VMA prots and walks each present PTE, ignoring installed
ones, even when pte_file() is on; their saved prots will be restored on
faults,
ignoring VMA ones and losing the mprotect() on them. So, in do_file_page(), we
must restore anyway VMA prots when the VMA is uniform, as we used to do before
this trail of patches."
It is only a bug because you hadn't plugged the hole -- make it fix up pte_file
ones as well.
Ulrich wanted to have code+data(+guard on 64-bit) into the same VMA, but I
left the code+data VMA joining away, to think more with it, since currently
it's too slow on swapout.
Yes, and it would be ridiculous to do this with non linear protections anyway.
If the vma code is so slow that glibc wants to merge code and data vmas together,
then we obviously need to fix the data structure (which will help everyone)
rather than hacking around it.
The other part is avoiding guard VMAs for thread stacks, and that could be
accomplished too by your proposal. Iff this work is held out, however.
I see no reason why they couldn't both go in. In fact, having an mmap flag for
adding guard regions around vmas (and perhaps eg. a system-wide / per-process
option for stack) could almost go in tomorrow.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
