lkml.org 
[lkml]   [2002]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: MM patches against 2.5.31
    On Mon, Aug 26, 2002 at 12:24:50PM -0700, Andrew Morton wrote:
    > The flaw is in doing the put_page_testzero() outside of any locking
    > which would prevent other CPUs from finding and "rescuing" the zero-recount
    > page.
    >
    > CPUA:
    > if (put_page_testzero()) {
    > /* Here's the window */
    > spin_lock(lru_lock);
    > list_del(page->lru);
    >
    > CPUB:
    >
    > spin_lock(lru_lock);
    > page = list_entry(lru);
    > page_cache_get(page); /* If this goes from 0->1, we die */
    > ...
    > page_cache_release(page); /* double free */

    So what we want CPUB do instead is

    spin_lock(lru_lock);
    page = list_entry(lru)

    START ATOMIC
    page_cache_get(page);
    res = (page_count (page) == 1)
    END ATOMIC

    if (res) {
    atomic_dec (&page->count);
    continue; /* with next page */
    }
    ...
    page_cache_release (page);

    I.e. we want to detect _atomically_ that we just raised the page count
    from zero to one. My patch actually has a solution that implements the
    needed atomic operation above by means of the atomic functions that we
    currently have on all archs (it's called get_page_testzero and
    should probably called get_page_testone).
    The more I think about this the more I think this is the way to go.

    regards Christian

    --
    THAT'S ALL FOLKS!
    -
    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:28    [W:2.579 / U:0.248 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site