Messages in this thread | | | Date | Sun, 12 Feb 2006 13:54:57 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 1/3] compound page: use page[1].lru |
| |
Hugh Dickins <hugh@veritas.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |