lkml.org 
[lkml]   [2011]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Don't mlock guardpage if the stack is growing up
    Dne 12.5.2011 04:12, Linus Torvalds napsal(a):
    > On Wed, May 11, 2011 at 1:42 AM, Milan Broz <mbroz@redhat.com> wrote:
    >>
    >> Another one is cryptsetup [..]
    >
    > Quite frankly, all security-related uses should always be happy about
    > a "MCL_SPARSE" model, since there is no point in ever bringing in
    > pages that haven't been used. The whole (and only) point of
    > mlock[all]() for them is the "avoid to push to disk" issue.
    >
    > I do wonder if we really should ever do the page-in at all. We might
    > simply be better off always just saying "we'll lock pages you've
    > touched, that's it".
    >


    For LVM we need to ensure the code which might ever be executed during disk
    suspend state must be paged and locked in - thus we would need MCL_SPARSE only
    on several selected 'unneeded' libraries - as we are obviously not really able
    to select which part of glibc might be needed during all code path (though I
    guess we may find some limits). But if we are sure that some libraries and
    locale files will never be used during suspend state - we do not care about
    those pages at all.

    So it's not like we would always need only MCL_SPARSE all the time - we would
    probably need to have some control to switch i.e. glibc into MCL_ALL.

    Zdenek


    \
     
     \ /
      Last update: 2011-05-12 11:09    [W:2.738 / U:0.756 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site