From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with ESMTP id 5FB7E6B002D for ; Thu, 10 Nov 2011 13:22:24 -0500 (EST) Received: from [193.150.134.105] (helo=serv30.sepura.co.uk) by mta01 with esmtp (Exim 4.02) id 1ROZGV-00002Q-00 for linux-mm@kvack.org; Thu, 10 Nov 2011 18:22:19 +0000 Received: from p4admin by serv30.sepura.co.uk with local (Exim 4.71) (envelope-from ) id 1ROZG1-00060q-BO for linux-mm@kvack.org; Thu, 10 Nov 2011 18:21:49 +0000 Date: Thu, 10 Nov 2011 18:21:49 +0000 Message-Id: From: p4admin@sepura.com Reply-To: devtools@sepura.com ((Account for building software - Daniel Sherwood)) Subject: Perforce change 315103 Content-Type: multipart/alternative; boundary="MCBoundary=_111111018222006601" Sender: owner-linux-mm@kvack.org List-ID: Cc: linux-mm@kvack.org --MCBoundary=_111111018222006601 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Change 315103 by devtools@devtools_gitimport on 2011/11/10 18:21:16 =09commit 7bf07f3d4b4358aa6d99a26d7a0165f1e91c3fcc =09Author: Adam Litke =09Date: Sat Sep 3 15:55:00 2005 -0700 =09 =09 [PATCH] hugetlb: move stale pte check into huge_pte_alloc() =09 =09 Initial Post (Wed, 17 Aug 2005) =09 =09 This patch moves the =09 =09if (! pte_none(*pte)) =09 =09=09hugetlb_clean_stale_pgtable(pte); =09 logic into huge_pte_alloc() so all of its callers can be immune to t= he bug =09 described by Kenneth Chen at http://lkml.org/lkml/2004/6/16/246 =09 =09 > It turns out there is a bug in hugetlb_prefault(): with 3 level pa= ge table, =09 > huge_pte_alloc() might return a pmd that points to a PTE page. It = happens =09 > if the virtual address for hugetlb mmap is recycled from previousl= y used =09 > normal page mmap. free_pgtables() might not scrub the pmd entry on =09 > munmap and hugetlb_prefault skips on any pmd presence regardless w= hat type =09 > it is. =09 =09 Unless I am missing something, it seems more correct to place the ch= eck inside =09 huge_pte_alloc() to prevent a the same bug wherever a huge pte is al= located. =09 It also allows checking for this condition when lazily faulting huge= pages =09 later in the series. =09 =09 Signed-off-by: Adam Litke =09 Cc: =09 Signed-off-by: Andrew Morton =09 Signed-off-by: Linus Torvalds Affected files ... ... //sw/components_third_party/linux/git/master/.versions.submit#1694 edit ... //sw/components_third_party/linux/git/master/component/arch/i386/mm/hug= etlbpage.c#4 edit ... //sw/components_third_party/linux/git/master/component/mm/hugetlb.c#4 e= dit http://serv30:8666/315103?ac=3D10 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=92s Road, Cambridge, = CB4 1GR, England. Registered in England and Wales. Registration Number 4353= 801 =20 --MCBoundary=_111111018222006601 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Change 315103 by devtool= s@devtools_gitimport on 2011/11/10 18:21:16

=09commit 7bf07f3d4b4358aa6d99a26d7a0165f1e91c3fcc
=09Author: Adam Litke <agl@us.ibm.com<= /a>>
=09Date: Sat Sep 3 15:55:00 2005 -0700
=09
=09 [PATCH] hugetlb: move stale pte check into huge_pte_alloc()
=09
=09 Initial Post (Wed, 17 Aug 2005)
=09
=09 This patch moves the
=09 =09if (! pte_none(*pte))
=09 =09=09hugetlb_clean_stale_pgtable(pte);
=09 logic into huge_pte_alloc() so all of its callers can be immune to t= he bug
=09 described by Kenneth Chen at http://lkml.org/lkml/2004/6/16/246
=09
=09 > It turns out there is a bug in hugetlb_prefault(): with 3 level= page table,
=09 > huge_pte_alloc() might return a pmd that points to a PTE page. = It happens
=09 > if the virtual address for hugetlb mmap is recycled from previo= usly used
=09 > normal page mmap. free_pgtables() might not scrub the pmd entry= on
=09 > munmap and hugetlb_prefault skips on any pmd presence regardles= s what type
=09 > it is.
=09
=09 Unless I am missing something, it seems more correct to place the ch= eck inside
=09 huge_pte_alloc() to prevent a the same bug wherever a huge pte is al= located.
=09 It also allows checking for this condition when lazily faulting huge= pages
=09 later in the series.
=09
=09 Signed-off-by: Adam Litke <agl@= us.ibm.com>
=09 Cc: <linux-mm@kvack.org= >
=09 Signed-off-by: Andrew Morton <ak= pm@osdl.org>
=09 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/hug= etlbpage.c#4 edit
... //sw/components_third_party/linux/git/master/component/mm/hugetlb.c#4 e= dit

http://se= rv30:8666/315103?ac=3D10


=20
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=92s Road, Cambridge, = CB4 1GR, England. Registered in England and Wales. Registration Number 4353= 801
=20
This email message has been scanned for viruses by Mimecast.
Mimecast delivers a complete managed email solution from a single we= b based platform.
=20 --MCBoundary=_111111018222006601-- -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org