rmap: fix page_address_in_vma() to walk through anon_vma_chain
in [Kernel]
|
Prev: mm,migration: Allow the migration of PageSwapCache pages
Next: [PATCH] blk-cgroup: Fix RCU correctness warning in cfq_init_queue()
From: Rik van Riel on 22 Apr 2010 11:20 On 04/22/2010 01:42 AM, Naoya Horiguchi wrote: > I found a bug on page_address_in_vma() related to anon_vma_chain. > > I wrote a patch, but according to a comment in include/linux/rmap.h, > I suspect this doesn't meet lock requirement of anon_vma_chain > (mmap_sem and page_table_lock, see below). > > mmap_sem page_table_lock > mm/ksm.c: > write_protect_page() hold not hold > replace_page() hold not hold > mm/memory-failure.c: > add_to_kill() not hold hold > mm/mempolicy.c: > new_vma_page() hold not hold > mm/swapfile.c: > unuse_vma() hold not hold > > Any comments? Good catch. However, for anonymous pages, page_address_in_vma only ever determined whether the page _could_ be part of the VMA, never whether it actually was. The function page_address_in_vma has always given false positives, which means all of the callers already check that the page is actually part of the process. This means we may be able to get away with not verifying the anon_vma at all. After all, verifying that the VMA has the anon_vma mapped does not mean the VMA has this page... Doing away with that check gets rid of your locking conundrum :) Opinions? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |