From: p4admin@sepura.com
Cc: linux-mm@kvack.org
Subject: Perforce change 315103
Date: Thu, 10 Nov 2011 18:21:49 +0000 [thread overview]
Message-ID: <E1ROZG1-00060q-BO@serv30.sepura.co.uk> (raw)
[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]
Change 315103 by devtools@devtools_gitimport on 2011/11/10 18:21:16
commit 7bf07f3d4b4358aa6d99a26d7a0165f1e91c3fcc
Author: Adam Litke <agl@us.ibm.com>
Date: Sat Sep 3 15:55:00 2005 -0700
[PATCH] hugetlb: move stale pte check into huge_pte_alloc()
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.
Signed-off-by: Adam Litke <agl@us.ibm.com>
Cc: <linux-mm@kvack.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Affected files ...
... //sw/components_third_party/linux/git/master/.versions.submit#1694 edit
... //sw/components_third_party/linux/git/master/component/arch/i386/mm/hugetlbpage.c#4 edit
... //sw/components_third_party/linux/git/master/component/mm/hugetlb.c#4 edit
http://serv30:8666/315103?ac=10
The information in this email is confidential. It is intended
solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any
disclosure, copying, or distribution is prohibited and may be
unlawful. If you have received this email in error please delete
it immediately and contact commercial@sepura.com.
Sepura plc. Registered Office: Radio House, St Andrew’s Road, Cambridge, CB4 1GR, England. Registered in England and Wales. Registration Number 4353801
[-- Attachment #2: Type: text/html, Size: 3289 bytes --]
reply other threads:[~2011-11-10 18:22 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=E1ROZG1-00060q-BO@serv30.sepura.co.uk \
--to=p4admin@sepura.com \
--cc=devtools@sepura.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox