• Hugh Dickins's avatar
    [PATCH] compound page: use page[1].lru · 41d78ba5
    Hugh Dickins authored
    If a compound page has its own put_page_testzero destructor (the only current
    example is free_huge_page), that is noted in page[1].mapping of the compound
    page.  But that's rather a poor place to keep it: functions which call
    set_page_dirty_lock after get_user_pages (e.g.  Infiniband's
    __ib_umem_release) ought to be checking first, otherwise set_page_dirty is
    liable to crash on what's not the address of a struct address_space.
    And now I'm about to make that worse: it turns out that every compound page
    needs a destructor, so we can no longer rely on hugetlb pages going their own
    special way, to avoid further problems of page->mapping reuse.  For example,
    not many people know that: on 50% of i386 -Os builds, the first tail page of a
    compound page purports to be PageAnon (when its destructor has an odd
    address), which surprises page_add_file_rmap.
    Keep the compound page destructor in page[1].lru.next instead.  And to free up
    the common pairing of mapping and index, also move compound page order from
    index to lru.prev.  Slab reuses page->lru too: but if we ever need slab to use
    compound pages, it can easily stack its use above this.
    (akpm: decoded version of the above: the tail pages of a compound page now
    have ->mapping==NULL, so there's no need for the set_page_dirty[_lock]()
    caller to check that they're not compund pages before doing the dirty).
    Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
page_alloc.c 66.7 KB