[lkml]   [2003]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.5.66-mm2] Fix page_convert_anon locking issues
    On Thu, 3 Apr 2003, Dave McCracken wrote:
    > I thought of a big hole in the simpler scheme you suggested. It occurred
    > to me that try_to_unmap will fail. It will see the PageAnon flag so it'll
    > just walk the pte_chain and assume it doesn't have to walk the vmas. This
    > will leave the page with some stranded mappings. Actually
    > page_convert_anon will then finish, and we'll have a page where
    > try_to_unmap claims it has succeeded but still has mappings.

    I don't see that as a big hole at all. While we're in page_convert_anon,
    yes, page_referenced won't find all the ptes and try_to_unmap won't be
    able to unmap them all; but there are plenty of other reasons why a page
    may be briefly unfreeable even though try_to_unmap succeeded, it'll just
    try again later.

    I haven't really had my think yet, but the only difficulty I've seen so
    far is in maintaining the nr_mapped stats correctly. page_convert_anon
    insert an initial dummy entry (the entry install_page is about to add?)
    to make sure page_mapped cannot go false?

    (Hmm, is the current page_convert_anon maintaining nr_reverse_maps
    correctly? I would think not, since it's doing nothing about it, and
    page_remove_rmap would decrement seeing an Anon. But perhaps I'm
    confused again, a quick test doesn't show the drop I'd expect.)


    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:34    [W:0.020 / U:3.704 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site