diff options
| author | Dave Hansen <haveblue@us.ibm.com> | 2004-06-29 05:21:13 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2004-06-29 05:21:13 -0700 |
| commit | 8bfb70922e15d80d3ecd7956fe148b04101f831c (patch) | |
| tree | 86f10d61f2c36574ecf9c7ed7c022285004764d7 /mm | |
| parent | c25e4809a735fb8798b3d717f15470a70631154e (diff) | |
| download | history-8bfb70922e15d80d3ecd7956fe148b04101f831c.tar.gz | |
[PATCH] fix page->count discrepancy for zero page
While writing some analysis tools for memory hot-remove, we came across a
single page which had a ->count that always increased, without bound. It
ended up always being the zero page, and it was caused by a leaked
reference in some do_wp_page() code that ends up avoiding PG_reserved
pages.
Basically what happens is that page_cache_release()/put_page() ignore
PG_reserved pages, while page_cache_get()/get_page() go ahead and take the
reference. So, each time there's a COW fault on the zero-page, you get a
leaked page->count increment.
It's pretty rare to have a COW fault on anything that's PG_reserved, in
fact, I can't think of anything else that this applies to other than the
zero page.
In any case, it the bug doesn't cause any real problems, but it is a bit of
an annoyance and is obviously incorrect. We've been running with this
patch for about 3 months now, and haven't run into any problems with it.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'mm')
| -rw-r--r-- | mm/memory.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/mm/memory.c b/mm/memory.c index 0404594104a5f3..8738b38ac628b9 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1078,7 +1078,8 @@ static int do_wp_page(struct mm_struct *mm, struct vm_area_struct * vma, /* * Ok, we need to copy. Oh, well.. */ - page_cache_get(old_page); + if (!PageReserved(old_page)) + page_cache_get(old_page); spin_unlock(&mm->page_table_lock); if (unlikely(anon_vma_prepare(vma))) |