lkml.org 
[lkml]   [2010]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] mlock/stack guard interaction fixup
    On Sun, Aug 22, 2010 at 11:21:34AM -0700, Linus Torvalds wrote:
    > On Sun, Aug 22, 2010 at 10:25 AM, Greg KH <gregkh@suse.de> wrote:
    > >>
    > >> Greg, we are talking about:
    > >> 0e8e50e20c837eeec8323bba7dcd25fe5479194c mm: make stack guard page logic use vm_prev pointer
    > >> 7798330ac8114c731cfab83e634c6ecedaa233d7 mm: make the mlock() stack guard page checks stricter
    > >> 297c5eee372478fc32fec5fe8eed711eedb13f3d mm: make the vma list be doubly linked
    > >
    > > I must be missing something, but aren't these patches just "cleanups"
    > > and changing the logic here to be nicer? ?Or do they fix real problems
    > > with the previous stack guard stuff?
    > >
    > > Is it the second one you really need here?
    >
    > They're all "required" (#2 needs #1, and #3 is a fix for something
    > that can happen in the same circumstances that #2 makes any
    > difference).

    Ok, thanks.

    > Although you do need to have some really odd things going on for any
    > of them to make any difference. Notably, you need to do mlock or
    > mprotect on the stack segment, which no sane program does.
    >
    > That said, the change from
    >
    > start += PAGE_SIZE;
    >
    > to
    >
    > addr += PAGE_SIZE;
    >
    > in __mlock_vma_pages_range() (in #3) is a bugfix even for the normal
    > mlockall() case. Not that anybody will realistically care about that
    > either: the failure case just doesn't really realistically ever matter
    > (it expands the stack which the code tries to avoid, and possibly
    > forgets to mlock the bottom of the stack).
    >
    > So I wouldn't call them high priority. Ian is doing something _really_
    > odd. Doing hypercalls from user space on stuff that is on the stack,
    > rather than just copying it to some stable area is dodgy. And I
    > guarantee that doing the crazy mlock dance is slower than the copy, so
    > it's complex, fragile, _and_ slow.

    Heh, ok, I'll not worry about this for the .27 kernel then, that makes
    it a lot easier for me :)

    thanks,

    greg k-h


    \
     
     \ /
      Last update: 2010-08-22 21:11    [W:0.025 / U:1.828 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site