lkml.org 
[lkml]   [2003]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] invalidate_mmap_range() misses remap_file_pages()-affected targets
    On Sun, 12 Oct 2003, William Lee Irwin III wrote:
    >> invalidate_mmap_range(), and hence vmtruncate(), can miss its targets
    >> due to remap_file_pages()

    On Sun, Oct 12, 2003 at 04:28:09PM -0400, Rik van Riel wrote:
    > Please don't. Remap_file_pages() not 100% working the way
    > a normal mmap() works should be a case of "doctor, it hurts".
    > Making the VM more complex just to support the (allegedly
    > low overhead) hack of remap_file_pages() doesn't seem like
    > a worthwhile tradeoff to me.
    > In fact, I wouldn't mind if remap_file_pages() was simplified ;)

    I'm far less concerned about userspace shooting itself in the foot
    than I am the kernel.

    At some point a decision was made to at least try to prevent orphaned
    pages arising from vmtruncate() vs. ->nopage(), with some userspace
    semantic motive I'm not concerned about, and to mitigate or possibly
    eliminate the need to handle the orphaned pages in-kernel, which is my
    concern. This tries to finish getting rid of Morton pages.

    The only complexity to be concerned about here is algorithmic; a hotly
    contended lock is taken in the VM_NONLINEAR setting, and the pagetable
    scan to find pages at vm_pgoff-unaligned ptes is an exhaustive search.
    The algorithm itself is a trivial derivative of zap_page_range() that
    just checks page->index before unmapping pages and is no cause for
    concern with respect to complexity of implementation.

    I appreciate the desire for simplicity in general, but walking
    pagetables when needed isn't complex, especially with such a large
    cut and paste component. The proper interpretation of this is as an
    attempt to complete the simplification of eliminating Morton pages.


    -- wli

    (Prior to the attempt that was merged, there was a tradeoff between
    best effort search for the ptes and just deliberately letting Morton
    pages happen. Since it was merged, it's become a core kernel semantic
    question: i.e. is the vmtruncate() atomicity solely for the benefit of
    "naive userspace", or is it a new kernel invariant? I tend to favor
    consistency, but it's ultimately arbitrary, hence [RFC].)
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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