summaryrefslogtreecommitdiffstats
path: root/debian/patches-rt/0310-Revert-ARM-Initialize-split-page-table-locks-for-vec.patch
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--debian/patches-rt/0310-Revert-ARM-Initialize-split-page-table-locks-for-vec.patch87
1 files changed, 87 insertions, 0 deletions
diff --git a/debian/patches-rt/0310-Revert-ARM-Initialize-split-page-table-locks-for-vec.patch b/debian/patches-rt/0310-Revert-ARM-Initialize-split-page-table-locks-for-vec.patch
new file mode 100644
index 000000000..92464be91
--- /dev/null
+++ b/debian/patches-rt/0310-Revert-ARM-Initialize-split-page-table-locks-for-vec.patch
@@ -0,0 +1,87 @@
+From 24329bb57c5b6fae2c3360adcb2c69bbcd4314f4 Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Date: Fri, 18 Oct 2019 13:04:15 +0200
+Subject: [PATCH 310/347] Revert "ARM: Initialize split page table locks for
+ vector page"
+Origin: https://www.kernel.org/pub/linux/kernel/projects/rt/4.19/older/patches-4.19.246-rt110.tar.xz
+
+[ Upstream commit 247074c44d8c3e619dfde6404a52295d8d671d38 ]
+
+I'm dropping this patch, with its original description:
+
+|ARM: Initialize split page table locks for vector page
+|
+|Without this patch, ARM can not use SPLIT_PTLOCK_CPUS if
+|PREEMPT_RT_FULL=y because vectors_user_mapping() creates a
+|VM_ALWAYSDUMP mapping of the vector page (address 0xffff0000), but no
+|ptl->lock has been allocated for the page. An attempt to coredump
+|that page will result in a kernel NULL pointer dereference when
+|follow_page() attempts to lock the page.
+|
+|The call tree to the NULL pointer dereference is:
+|
+| do_notify_resume()
+| get_signal_to_deliver()
+| do_coredump()
+| elf_core_dump()
+| get_dump_page()
+| __get_user_pages()
+| follow_page()
+| pte_offset_map_lock() <----- a #define
+| ...
+| rt_spin_lock()
+|
+|The underlying problem is exposed by mm-shrink-the-page-frame-to-rt-size.patch.
+
+The patch named mm-shrink-the-page-frame-to-rt-size.patch was dropped
+from the RT queue once the SPLIT_PTLOCK_CPUS feature (in a slightly
+different shape) went upstream (somewhere between v3.12 and v3.14).
+
+I can see that the patch still allocates a lock which wasn't there
+before. However I can't trigger a kernel oops like described in the
+patch by triggering a coredump.
+
+Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+---
+ arch/arm/kernel/process.c | 24 ------------------------
+ 1 file changed, 24 deletions(-)
+
+diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
+index 8d3c7ce34c24..82ab015bf42b 100644
+--- a/arch/arm/kernel/process.c
++++ b/arch/arm/kernel/process.c
+@@ -324,30 +324,6 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
+ }
+
+ #ifdef CONFIG_MMU
+-/*
+- * CONFIG_SPLIT_PTLOCK_CPUS results in a page->ptl lock. If the lock is not
+- * initialized by pgtable_page_ctor() then a coredump of the vector page will
+- * fail.
+- */
+-static int __init vectors_user_mapping_init_page(void)
+-{
+- struct page *page;
+- unsigned long addr = 0xffff0000;
+- pgd_t *pgd;
+- pud_t *pud;
+- pmd_t *pmd;
+-
+- pgd = pgd_offset_k(addr);
+- pud = pud_offset(pgd, addr);
+- pmd = pmd_offset(pud, addr);
+- page = pmd_page(*(pmd));
+-
+- pgtable_page_ctor(page);
+-
+- return 0;
+-}
+-late_initcall(vectors_user_mapping_init_page);
+-
+ #ifdef CONFIG_KUSER_HELPERS
+ /*
+ * The vectors page is always readable from user space for the
+--
+2.36.1
+