linux-kernel - [PATCH 05/10] ksm: no debug in page_dup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1247851850-4298-6-git-send-email-ieidus@redhat.com>
Date:	Fri, 17 Jul 2009 20:30:45 +0300
From:	Izik Eidus <ieidus@...hat.com>
To:	akpm@...ux-foundation.org
Cc:	hugh.dickins@...cali.co.uk, aarcange@...hat.com, chrisw@...hat.com,
	avi@...hat.com, riel@...hat.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, nickpiggin@...oo.com.au, ieidus@...hat.com,
	Nick Piggin <npiggin@...e.de>
Subject: [PATCH 05/10] ksm: no debug in page_dup_rmap()

From: Hugh Dickins <hugh.dickins@...cali.co.uk>

page_dup_rmap(), used on each mapped page when forking,  was originally
just an inline atomic_inc of mapcount.  2.6.22 added CONFIG_DEBUG_VM
out-of-line checks to it, which would need to be ever-so-slightly
complicated to allow for the PageKsm() we're about to define.

But I think these checks never caught anything.  And if it's coding
errors we're worried about, such checks should be in page_remove_rmap()
too, not just when forking; whereas if it's pagetable corruption we're
worried about, then they shouldn't be limited to CONFIG_DEBUG_VM.

Oh, just revert page_dup_rmap() to an inline atomic_inc of mapcount.

Signed-off-by: Hugh Dickins <hugh.dickins@...cali.co.uk>
Signed-off-by: Chris Wright <chrisw@...hat.com>
Signed-off-by: Izik Eidus <ieidus@...hat.com>
Cc: Nick Piggin <npiggin@...e.de>
---
 include/linux/rmap.h |    6 +-----
 mm/memory.c          |    2 +-
 mm/rmap.c            |   21 ---------------------
 3 files changed, 2 insertions(+), 27 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index bf116d0..477841d 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -71,14 +71,10 @@ void page_add_new_anon_rmap(struct page *, struct vm_area_struct *, unsigned lon
 void page_add_file_rmap(struct page *);
 void page_remove_rmap(struct page *);
 
-#ifdef CONFIG_DEBUG_VM
-void page_dup_rmap(struct page *page, struct vm_area_struct *vma, unsigned long address);
-#else
-static inline void page_dup_rmap(struct page *page, struct vm_area_struct *vma, unsigned long address)
+static inline void page_dup_rmap(struct page *page)
 {
 	atomic_inc(&page->_mapcount);
 }
-#endif
 
 /*
  * Called from mm/vmscan.c to handle paging out
diff --git a/mm/memory.c b/mm/memory.c
index 8159a62..8b1922c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -595,7 +595,7 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm,
 	page = vm_normal_page(vma, addr, pte);
 	if (page) {
 		get_page(page);
-		page_dup_rmap(page, vma, addr);
+		page_dup_rmap(page);
 		rss[!!PageAnon(page)]++;
 	}
 
diff --git a/mm/rmap.c b/mm/rmap.c
index 836c6c6..ab84e45 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -709,27 +709,6 @@ void page_add_file_rmap(struct page *page)
 	}
 }
 
-#ifdef CONFIG_DEBUG_VM
-/**
- * page_dup_rmap - duplicate pte mapping to a page
- * @page:	the page to add the mapping to
- * @vma:	the vm area being duplicated
- * @address:	the user virtual address mapped
- *
- * For copy_page_range only: minimal extract from page_add_file_rmap /
- * page_add_anon_rmap, avoiding unnecessary tests (already checked) so it's
- * quicker.
- *
- * The caller needs to hold the pte lock.
- */
-void page_dup_rmap(struct page *page, struct vm_area_struct *vma, unsigned long address)
-{
-	if (PageAnon(page))
-		__page_check_anon_rmap(page, vma, address);
-	atomic_inc(&page->_mapcount);
-}
-#endif
-
 /**
  * page_remove_rmap - take down pte mapping from a page
  * @page: page to remove mapping from
-- 
1.5.6.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/