[lkml]   [2001]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: expand_stack fix [was Re: 2.4.9aa3]

    On Mon, 3 Sep 2001, Andrea Arcangeli wrote:
    > Linus please include the attached patch to the next kernel, expand_stack
    > is totally broken at the moment, we cannot mess with the mm vma layout
    > if we don't hold the mmap_sem in write mode.

    I disagree with the diagnosis..

    expand_stack() has _never_ messed with the vma layout, and never should.
    As such, from a vma list integrity standpoint it is fine.

    Do we mess with the contents? Yes. But I'd much rather see a much more
    minimal approach to the problem, on the order of:
    - make sure we only accept GROWSDOWN for anonymous areas (which don't
    care about the offset)
    - make the vm_start update atomic (possibly by just getting the pagetable

    > I considered implementing a read->write semaphore upgrade primitive but
    > it cannot be reliable

    There is no such thing. Never has been. It's a fundamentally impossible
    operation. We may, at some point, decide to have a "read_for_write()" and
    then "upgrade()" operations on the semaphore, but those inherently imply
    some level of single-threading (ie only one read-for-writer accepted at
    one time, with many pure readers), which makes it useless for this
    particular case anyway.

    However, having a finer-granularity spinlock _inside_ the semaphore (see
    above suggestion) is a perfectly valid approach.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:02    [W:0.022 / U:3.344 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site