From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org,
Linux Memory Management <linux-mm@kvack.org>,
Ulrich Drepper <drepper@redhat.com>,
Val Henson <val.henson@intel.com>
Subject: Re: [patch 00/14] remap_file_pages protection support
Date: Sat, 06 May 2006 19:06:31 +1000 [thread overview]
Message-ID: <445C6717.1000402@yahoo.com.au> (raw)
In-Reply-To: <200605030245.01457.blaisorblade@yahoo.it>
Blaisorblade wrote:
> On Tuesday 02 May 2006 05:45, Nick Piggin wrote:
>
>>blaisorblade@yahoo.it 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
next prev parent reply other threads:[~2006-05-06 9:21 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-30 17:29 [patch 00/14] remap_file_pages protection support blaisorblade
2006-04-30 17:29 ` [patch 01/14] Fix comment about remap_file_pages blaisorblade
2006-04-30 17:29 ` [patch 02/14] remap_file_pages protection support: add needed macros blaisorblade
2006-04-30 17:29 ` [patch 03/14] remap_file_pages protection support: handle MANYPROTS VMAs blaisorblade
2006-04-30 17:29 ` [patch 04/14] remap_file_pages protection support: disallow mprotect() on manyprots mappings blaisorblade
2006-04-30 17:29 ` [patch 05/14] remap_file_pages protection support: cleanup syscall checks blaisorblade
2006-04-30 17:29 ` [patch 06/14] remap_file_pages protection support: enhance syscall interface blaisorblade
2006-04-30 17:30 ` [patch 07/14] remap_file_pages protection support: support private vma for MAP_POPULATE blaisorblade
2006-04-30 17:30 ` [patch 08/14] remap_file_pages protection support: use FAULT_SIGSEGV for protection checking blaisorblade
2006-04-30 17:30 ` [patch 09/14] remap_file_pages protection support: fix race condition with concurrent faults on same address space blaisorblade
2006-04-30 17:30 ` [patch 10/14] remap_file_pages protection support: fix get_user_pages() on VM_MANYPROTS vmas blaisorblade
2006-04-30 17:30 ` [patch 11/14] remap_file_pages protection support: pte_present should not trigger on PTE_FILE PROTNONE ptes blaisorblade
2006-05-02 3:53 ` Nick Piggin
2006-05-03 1:29 ` Blaisorblade
2006-05-06 10:03 ` Nick Piggin
2006-05-07 17:50 ` Blaisorblade
2006-04-30 17:30 ` [patch 12/14] remap_file_pages protection support: also set VM_NONLINEAR on nonuniform VMAs blaisorblade
2006-04-30 17:30 ` [patch 13/14] remap_file_pages protection support: uml, i386, x64 bits blaisorblade
2006-04-30 17:30 ` [patch 14/14] remap_file_pages protection support: adapt to uml peculiarities blaisorblade
2006-05-02 3:45 ` [patch 00/14] remap_file_pages protection support Nick Piggin
2006-05-02 3:56 ` Nick Piggin
2006-05-02 11:24 ` Ingo Molnar
2006-05-02 12:19 ` Nick Piggin
2006-05-02 17:16 ` Lee Schermerhorn
2006-05-03 1:20 ` Blaisorblade
2006-05-03 14:35 ` Lee Schermerhorn
2006-05-03 0:25 ` Blaisorblade
2006-05-06 16:05 ` Ulrich Drepper
2006-05-07 4:22 ` Nick Piggin
2006-05-13 14:13 ` Nick Piggin
2006-05-13 18:19 ` Valerie Henson
2006-05-13 22:54 ` Valerie Henson
2006-05-16 13:30 ` Nick Piggin
2006-05-16 13:51 ` Andreas Mohr
2006-05-16 16:31 ` Valerie Henson
2006-05-16 16:47 ` Andreas Mohr
2006-05-17 3:25 ` Nick Piggin
2006-05-17 6:10 ` Blaisorblade
2006-05-16 16:33 ` Valerie Henson
2006-05-03 0:44 ` Blaisorblade
2006-05-06 9:06 ` Nick Piggin [this message]
2006-05-06 15:26 ` Ulrich Drepper
2006-05-02 10:21 ` Arjan van de Ven
2006-05-02 23:46 ` Valerie Henson
2006-05-03 0:26 ` Blaisorblade
2006-05-03 1:44 ` Ulrich Drepper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=445C6717.1000402@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=blaisorblade@yahoo.it \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=val.henson@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox