lkml.org 
[lkml]   [2006]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [patch 00/14] remap_file_pages protection support
    Date
    On Tuesday 02 May 2006 19:16, Lee Schermerhorn wrote:
    > On Tue, 2006-05-02 at 13:45 +1000, Nick Piggin wrote:
    > > blaisorblade@yahoo.it wrote:

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

    > One way I've seen this done on other systems

    I'm curious, which ones?

    > is to use something like a
    > prio tree [e.g., see the shared policy support for shmem] for sub-vma
    > protection ranges.
    Which sub-vma ranges? The ones created with mprotect?

    I'm curious about what is the difference between this sub-tree and the main
    tree... you have some point, but I miss which one :-) Actually when doing a
    lookup in the main tree the extra nodes in the subtree are not searched, so
    you get an advantage.

    One possible point is that a VMA maps to one mmap() call (with splits from
    mremap(),mprotect(),partial munmap()s), and then they use sub-VMAs instead of
    VMA splits.

    > Most vmas [I'm guessing here] will have only the
    > original protections or will be reprotected in toto.

    > So, one need only
    > allocate/populate the protection tree when sub-vma protections are
    > requested. Then, one can test protections via the vma, perhaps with
    > access/check macros to hide the existence of the protection tree. Of
    > course, adding a tree-like structure could introduce locking
    > complications/overhead in some paths where we'd rather not [just
    > guessing again]. Might be more overhead than just mucking with the ptes
    > [for UML], but would keep the ptes in sync with the vma's view of
    > "protectedness".
    >
    > Lee

    Ok, there are two different situations, I'm globally unconvinced until I
    understand the usefulness of a different sub-tree.

    a) UML. The answer is _no_ to all guesses, since we must implement page tables
    of a guest virtual machine via mmap() or remap_file_pages. And they're as
    fragmented as they get (we get one-page-wide VMAs currently).

    b) the proposed glibc usage. The original Ulrich's request (which I cut down
    because of problems with objrmap) was to have one mapping per DSO, including
    code,data and guard page. So you have three protections in one VMA.

    However, this is doable via this remap_file_pages, adding something for
    handling private VMAs (handling movement of the anonymous memory you get on
    writes); but it's slow on swapout, since it stops using objrmap. So I've not
    thought to do it.
    --
    Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
    Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
    http://www.user-mode-linux.org/~blaisorblade
    Chiacchiera con i tuoi amici in tempo reale!
    http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-05-03 03:24    [W:4.135 / U:2.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site