lkml.org 
[lkml]   [1999]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Patch] shm bug introduced with pagecache in 2.3.11


    On Thu, 25 Nov 1999, Andrea Arcangeli wrote:
    >
    > If you allow more than one task to fault for example in the swapin path
    > you'll get in troubles as you can't solve this race cleanly with a
    > spinlock. That's why I added the semaphore to the shm segments in first
    > place.

    No, you can solve it cleanly by just changing the code: you only really
    need to guarantee that the mapping doesn't change under you (that would be
    disastrous and very hard to recover from). Somebody else filling in the
    page before you is simple to check for.

    > Only replacing the down() with a read_down() in do_page_fault is _not_
    > enough. The semaphore is not there only to protect from mmap and vma
    > changes under us, right now it's there mainly to protect other threads to
    > fault under us.

    "mainly" is incorrect. The main protection is to maintain the vma list
    sanely, that was always the case (it used to be easy to crash the kernel
    by using threads that pagefaulted and mmap'ed at the same time).

    Protecting against others paging in is trivial, and in fact we used to do
    that as long ago as 1.2.x if I remember correctly (the mm code was very
    different back then). The way we used to do that was to remember the
    original pte value, and before updating it with the newpage that was just
    paged in we just check that the pte value hasn't changed.

    In 1.2.x that protected us against threads that paged in simultaneously,
    and the races introduced by the IO waiting. But it was not enough to
    protect against mmap's changing the vma, so we introduced the semaphore in
    1.3.x, and because we had the semaphore we could also remove the
    optimistic checking.

    In 2.3.x, we can use the same trivial approach to protect against threads.
    It adds basically no overhead at all - we have to get the spinlock anyway,
    and the final check before changing the page tables is basically a single
    load and compare.

    Linus


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

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:2.548 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site