From: Adam Litke <agl@us.ibm.com>
To: linux-mm@kvack.org
Cc: christoph@lameter.com, ak@suse.de, kenneth.w.chen@intel.com,
david@gibson.dropbear.id.au
Subject: [PATCH 2/4] x86-move-stale-pgtable
Date: Wed, 17 Aug 2005 14:03:47 -0500 [thread overview]
Message-ID: <1124305427.3139.41.camel@localhost.localdomain> (raw)
In-Reply-To: <1124304966.3139.37.camel@localhost.localdomain>
Initial Post (Wed, 17 Aug 2005)
This patch moves the
if (! pte_none(*pte))
hugetlb_clean_stale_pgtable(pte);
logic into huge_pte_alloc() so all of its callers can be immune to the bug
described by Kenneth Chen at http://lkml.org/lkml/2004/6/16/246
> It turns out there is a bug in hugetlb_prefault(): with 3 level page table,
> huge_pte_alloc() might return a pmd that points to a PTE page. It happens
> if the virtual address for hugetlb mmap is recycled from previously used
> normal page mmap. free_pgtables() might not scrub the pmd entry on
> munmap and hugetlb_prefault skips on any pmd presence regardless what type
> it is.
Unless I am missing something, it seems more correct to place the check inside
huge_pte_alloc() to prevent a the same bug wherever a huge pte is allocated.
It also allows checking for this condition when lazily faulting huge pages
later in the series.
Diffed against 2.6.13-rc6-git7
Signed-off-by: Adam Litke <agl@us.ibm.com>
---
arch/i386/mm/hugetlbpage.c | 13 +++++++++++--
mm/hugetlb.c | 2 --
2 files changed, 11 insertions(+), 4 deletions(-)
diff -upN reference/arch/i386/mm/hugetlbpage.c current/arch/i386/mm/hugetlbpage.c
--- reference/arch/i386/mm/hugetlbpage.c
+++ current/arch/i386/mm/hugetlbpage.c
@@ -22,12 +22,21 @@ pte_t *huge_pte_alloc(struct mm_struct *
{
pgd_t *pgd;
pud_t *pud;
- pmd_t *pmd = NULL;
+ pmd_t *pmd;
+ pte_t *pte = NULL;
pgd = pgd_offset(mm, addr);
pud = pud_alloc(mm, pgd, addr);
pmd = pmd_alloc(mm, pud, addr);
- return (pte_t *) pmd;
+
+ if (!pmd)
+ goto out;
+
+ pte = (pte_t *) pmd;
+ if (!pte_none(*pte) && !pte_huge(*pte))
+ hugetlb_clean_stale_pgtable(pte);
+out:
+ return pte;
}
pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
diff -upN reference/mm/hugetlb.c current/mm/hugetlb.c
--- reference/mm/hugetlb.c
+++ current/mm/hugetlb.c
@@ -360,8 +360,6 @@ int hugetlb_prefault(struct address_spac
ret = -ENOMEM;
goto out;
}
- if (! pte_none(*pte))
- hugetlb_clean_stale_pgtable(pte);
idx = ((addr - vma->vm_start) >> HPAGE_SHIFT)
+ (vma->vm_pgoff >> (HPAGE_SHIFT - PAGE_SHIFT));
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2005-08-17 19:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-17 18:56 [PATCH 0/4] Demand faunting for huge pages Adam Litke
2005-08-17 19:03 ` [PATCH 1/4] x86-pte_huge Adam Litke
2005-08-17 19:18 ` Dave Hansen
2005-08-17 19:27 ` Adam Litke
2005-08-17 19:03 ` Adam Litke [this message]
2005-08-17 19:04 ` [PATCH 3/4] x86-walk-check Adam Litke
2005-08-17 19:41 ` Dave Hansen
2005-08-17 19:05 ` [PATCH 4/4] htlb-fault Adam Litke
2005-08-17 21:04 ` [PATCH 0/4] Demand faunting for huge pages Andi Kleen
2005-08-18 0:33 ` David Gibson
2005-08-18 0:35 ` Andi Kleen
2005-08-18 20:33 ` Adam Litke
2005-08-18 15:29 ` Ray Bryant
2005-08-18 20:29 ` Adam Litke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1124305427.3139.41.camel@localhost.localdomain \
--to=agl@us.ibm.com \
--cc=ak@suse.de \
--cc=christoph@lameter.com \
--cc=david@gibson.dropbear.id.au \
--cc=kenneth.w.chen@intel.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.