[lkml]   [1999]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: locking question: do_mmap(), do_munmap()

    On Tue, 12 Oct 1999 18:25:42 -0700 (PDT),
    (Kanoj Sarcar) said:

    > This is a skeleton of the solution that prevents kswapd from walking
    > down a vma chain without protections. I am trying to get comments on
    > this approach before I try a full blown implementation.

    > The rules:
    > 1. To modify the vmlist (add/delete), you must hold mmap_sem to
    > guard against clones doing mmap/munmap/faults, (ie all vm system
    > calls and faults), and from ptrace, swapin due to swap deletion
    > etc.
    > 2. To modify the vmlist (add/delete), you must also hold
    > vmlist_modify_lock, to guard against page stealers scanning the
    > list.
    > 3. To scan the vmlist, you must either
    > a. grab mmap_sem, which should be all cases except page stealer.
    > or
    > b. grab vmlist_access_lock, only done by page stealer.
    > 4. While holding the vmlist_modify_lock, you must be able to guarantee
    > that no code path will lead to page stealing.
    > 5. You must be able to guarantee that while holding vmlist_modify_lock
    > or vmlist_access_lock of mm A, you will not try to get either lock
    > for mm B.

    This looks like the same mechanism and set of rules that Al Viro
    proposed, and it seems watertight. I'd like the locking written down in
    the source somewhere if anyone implements this, btw, as otherwise we'll
    just be fixing it ourselves every time in the future when somebody who
    doesn't understand them touches anything in the mmap paths...


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

     \ /
      Last update: 2005-03-22 13:54    [W:0.021 / U:4.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site