lkml.org 
[lkml]   [1999]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] kanoj-mm17-2.3.21 kswapd vma scanning protection


    On Fri, 15 Oct 1999, Kanoj Sarcar wrote:
    >
    > The reason I am not very keen on this solution either is if you
    > consider process A holding vmlist_access_lock of B, going into swapout(),
    > where it tries to get a (sleeping) driver lock. Meanwhile, process B
    > has the driver lock, and is trying to grab the vmlist_update_lock on
    > itself, ie B, maybe to add/delete the vma. I do not think there is
    > such a driver currently though.

    I am convinced that all these games are unnecessary, and that the problem
    is fundamentally different. Not fixing up the current code, but just
    looking at the problem differently - making the deadlock go away by virtue
    of avoiding the critical regions.

    I think the suggestion to change the semantics of "swapout" is a good one.
    Now we have the mm layer passing down the vma to the IO layer, and hat
    makes everything more complex. I would certainly agree with just changing
    that semantic detail, and changing swapout to something like

    .. hold a spinlock - we can probably just reuse the
    page_table_lock for this to avoid multiple levels of locking
    here..

    file = fget(vma->vm_file);
    offset = file->f_offset + (address - vma->vm_start);
    flush_tlb_page(vma, address);
    spin_unlock(&vma->vm_mm->page_table_lock);

    error = file->f_ops->swapout(file, offset, page);
    fput(file);

    ...

    and then the other requirement would be that whenever the vma chain is
    physically modified, you also have to hold the page_table_lock.

    And finally, we rename the "page_table_lock" to the "page_stealer_lock",
    and we're all done.

    Does anybody see anything fundamentally wrong here? It looks like it
    should fix the problem without introducing any new locks, and without
    holding any locks across the actual physical swapout activity.

    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:54    [W:0.022 / U:0.756 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site