Hugh Dickins <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
