Patch "x86/mm: Fix vmalloc_fault() to handle large pages properly" has been added to the 4.4-stable tree
Subsystems (3)
This is a note to let you know that I've just added the patch titled
x86/mm: Fix vmalloc_fault() to handle large pages properly
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-mm-fix-vmalloc_fault-to-handle-large-pages-properly.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
f4eafd8bcd5229e998aa252627703b8462c3b90fMon Sep 17 00:00:00 2001
From: Toshi Kani <[email protected]>
Date: Wed, 17 Feb 2016 18:16:54 -0700
Subject: x86/mm: Fix vmalloc_fault() to handle large pages properly
From: Toshi Kani <[email protected]>
commit f4eafd8bcd5229e998aa252627703b8462c3b90f upstream.
A kernel page fault oops with the callstack below was observed when a read syscall was made to a pmem device after a huge amount (>512GB) of vmalloc ranges was allocated by ioremap() on a x86_64 system:
BUG: unable to handle kernel paging request at ffff880840000ff8
IP: vmalloc_fault+0x1be/0x300
PGD c7f03a067 PUD 0
Oops: 0000 [#1] SM
Call Trace:
__do_page_fault+0x285/0x3e0
do_page_fault+0x2f/0x80
? put_prev_entity+0x35/0x7a0
page_fault+0x28/0x30
? memcpy_erms+0x6/0x10
? schedule+0x35/0x80
? pmem_rw_bytes+0x6a/0x190 [nd_pmem]
? schedule_timeout+0x183/0x240
btt_log_read+0x63/0x140 [nd_btt]
:
? __symbol_put+0x60/0x60
? kernel_read+0x50/0x80
SyS_finit_module+0xb9/0xf0
entry_SYSCALL_64_fastpath+0x1a/0xa4Since v4.1, ioremap() supports large page (pud/pmd) mappings in x86_64 and PAE. vmalloc_fault() however assumes that the vmalloc range is limited to pte mappings.
vmalloc faults do not normally happen in ioremap'd ranges since ioremap() sets up the kernel page tables, which are shared by user processes. pgd_ctor() sets the kernel's PGD entries to user's during fork(). When allocation of the vmalloc ranges crosses a 512GB boundary, ioremap() allocates a new pud table and updates the kernel PGD entry to point it. If user process's PGD entry does not have this update yet, a read/write syscall to the range will cause a vmalloc fault, which hits the Oops above as it does not handle a large page properly.
Following changes are made to vmalloc_fault().
64-bit:
- No change for the PGD sync operation as it handles large pages already.
- Add pud_huge() and pmd_huge() to the validation code to handle large pages.
- Change pud_page_vaddr() to pud_pfn() since an ioremap range is not directly mapped (while the if-statement still works with a bogus addr).
- Change pmd_page() to pmd_pfn() since an ioremap range is not backed by struct page (while the if-statement still works with a bogus addr).
32-bit:
- No change for the sync operation since the index3 PGD entry covers the entire vmalloc range, which is always valid. (A separate change to sync PGD entry is necessary if this memory layout is changed regardless of the page size.)
- Add pmd_huge() to the validation code to handle large pages. This is for completeness since vmalloc_fault() won't happen in ioremap'd ranges as its PGD entry is always valid.
--- arch/x86/mm/fault.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
arch/x86/mm/fault.c +11 -4
@@ -287,6 +287,9 @@ static noinline int vmalloc_fault(unsignif (!pmd_k)return -1 ; +if (pmd_huge (*pmd_k)) +return 0 ; + pte_k =pte_offset_kernel (pmd_k, address);if (!pte_present (*pte_k))return -1 ;
@@ -360,8 +363,6 @@ void vmalloc_sync_all(void)* 64-bit: * * Handle a fault on the vmalloc area -* -* This assumes no large pages in there. */ static noinline int vmalloc_fault(unsigned long address) {
@@ -403,17 +404,23 @@ static noinline int vmalloc_fault(unsignif (pud_none (*pud_ref))return -1 ; -if (pud_none (*pud) ||pud_page_vaddr (*pud) !=pud_page_vaddr (*pud_ref)) +if (pud_none (*pud) ||pud_pfn (*pud) !=pud_pfn (*pud_ref))BUG (); +if (pud_huge (*pud)) +return 0 ; + pmd =pmd_offset (pud, address); pmd_ref =pmd_offset (pud_ref, address);if (pmd_none (*pmd_ref))return -1 ; -if (pmd_none (*pmd) ||pmd_page (*pmd) !=pmd_page (*pmd_ref)) +if (pmd_none (*pmd) ||pmd_pfn (*pmd) !=pmd_pfn (*pmd_ref))BUG (); +if (pmd_huge (*pmd)) +return 0 ; + pte_ref =pte_offset_kernel (pmd_ref, address);if (!pte_present (*pte_ref))return -1 ;
Patches currently in stable-queue which might be from [email protected] are
queue-4.4/x86-uaccess-64-handle-the-caching-of-4-byte-nocache-copies-properly-in-__copy_user_nocache.patch queue-4.4/devm_memremap_release-fix-memremap-d-addr-handling.patch queue-4.4/x86-mm-fix-vmalloc_fault-to-handle-large-pages-properly.patch queue-4.4/x86-uaccess-64-make-the-__copy_user_nocache-assembly-code-more-readable.patch