linux-kernel - [RFC][PATCH] mm: hugetlb: add stub-like do_hugetlb

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-next>] [day] [month] [year] [list]

Message-ID: <1427708426-31610-1-git-send-email-n-horiguchi@ah.jp.nec.com>
Date:	Mon, 30 Mar 2015 09:40:54 +0000
From:	Naoya Horiguchi <n-horiguchi@...jp.nec.com>
To:	"linux-mm@...ck.org" <linux-mm@...ck.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>, Hugh Dickins <hughd@...gle.com>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	David Rientjes <rientjes@...gle.com>,
	Rik van Riel <riel@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [RFC][PATCH] mm: hugetlb: add stub-like do_hugetlb_numa()

hugetlb doesn't support NUMA balancing now, but that doesn't mean that we
don't have to make hugetlb code prepared for PROTNONE entry properly.
In the current kernel, when a process accesses to hugetlb range protected
with PROTNONE, it causes unexpected COWs, which finally put hugetlb subsystem
into broken/uncontrollable state, where for example h->resv_huge_pages is
subtracted too much and wrapped around to a very large number, and free
hugepage pool is no longer maintainable.

This patch simply clears PROTNONE when it's caught out. Real NUMA balancing
code for hugetlb is not implemented yet (not sure how much it's worth doing.)

Signed-off-by: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
---
 include/asm-generic/hugetlb.h | 13 +++++++++++++
 mm/hugetlb.c                  | 24 ++++++++++++++++++++++++
 2 files changed, 37 insertions(+)

diff --git v4.0-rc4.orig/include/asm-generic/hugetlb.h v4.0-rc4/include/asm-generic/hugetlb.h
index 99b490b4d05a..7e73cc9e57b1 100644
--- v4.0-rc4.orig/include/asm-generic/hugetlb.h
+++ v4.0-rc4/include/asm-generic/hugetlb.h
@@ -37,4 +37,17 @@ static inline void huge_pte_clear(struct mm_struct *mm, unsigned long addr,
 	pte_clear(mm, addr, ptep);
 }
 
+#ifdef CONFIG_NUMA_BALANCING
+static inline int huge_pte_protnone(pte_t pte)
+{
+	return (pte_flags(pte) & (_PAGE_PROTNONE | _PAGE_PRESENT))
+		== _PAGE_PROTNONE;
+}
+#else
+static inline int huge_pte_protnone(pte_t pte)
+{
+	return 0;
+}
+#endif /* CONFIG_NUMA_BALANCING */
+
 #endif /* _ASM_GENERIC_HUGETLB_H */
diff --git v4.0-rc4.orig/mm/hugetlb.c v4.0-rc4/mm/hugetlb.c
index cbb0bbc6662a..18c169674ee4 100644
--- v4.0-rc4.orig/mm/hugetlb.c
+++ v4.0-rc4/mm/hugetlb.c
@@ -3090,6 +3090,28 @@ static int hugetlb_no_page(struct mm_struct *mm, struct vm_area_struct *vma,
 	goto out;
 }
 
+#ifdef CONFIG_NUMA_BALANCING
+/*
+ * NUMA balancing code is to be implemented. Now we just clear PROTNONE to
+ * avoid unstability of hugetlb subsystem.
+ */
+static int do_hugetlb_numa(struct mm_struct *mm, struct vm_area_struct *vma,
+				unsigned long address, pte_t *ptep, pte_t pte)
+{
+	spinlock_t *ptl = huge_pte_lockptr(hstate_vma(vma), mm, ptep);
+
+	spin_lock(ptl);
+	if (unlikely(!pte_same(*ptep, pte)))
+		goto unlock;
+	pte = pte_mkhuge(huge_pte_modify(pte, vma->vm_page_prot));
+	pte = pte_mkyoung(pte);
+	set_huge_pte_at(mm, address, ptep, pte);
+unlock:
+	spin_unlock(ptl);
+	return 0;
+}
+#endif
+
 #ifdef CONFIG_SMP
 static u32 fault_mutex_hash(struct hstate *h, struct mm_struct *mm,
 			    struct vm_area_struct *vma,
@@ -3144,6 +3166,8 @@ int hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
 	ptep = huge_pte_offset(mm, address);
 	if (ptep) {
 		entry = huge_ptep_get(ptep);
+		if (huge_pte_protnone(entry))
+			return do_hugetlb_numa(mm, vma, address, ptep, entry);
 		if (unlikely(is_hugetlb_entry_migration(entry))) {
 			migration_entry_wait_huge(vma, mm, ptep);
 			return 0;
-- 
1.9.3
--
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/