Re: [PATCH 1/3] compound page: use page[1].lru

[Andrew Morton]

Hugh Dickins <hugh@xxxxxxxxxxx> wrote:
>
> 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.

I'm scratching my head over flush_dcache_page() on, say, sparc64.  For
example, the one in fs/direct-io.c.  With this patch, we'll call
flush_dcache_page_impl(), which at least won't crash.  Before the patch I
think we'd just do random stuff.

But I'm not sure that flush_dcache_page(hugetlb tail page) will do the
right thing in aither case?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/