* [PATCH RT] Revert "ARM: Initialize split page table locks for vector page"
@ 2019-10-14 16:02 Sebastian Andrzej Siewior
2019-10-15 16:26 ` Matthew Wilcox
0 siblings, 1 reply; 3+ messages in thread
From: Sebastian Andrzej Siewior @ 2019-10-14 16:02 UTC (permalink / raw)
To: linux-kernel, linux-mm
Cc: Frank Rowand, Peter Zijlstra, Thomas Gleixner, Steven Rostedt
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.
---
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 1041300022177..f934a6739fc05 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -325,30 +325,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.23.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH RT] Revert "ARM: Initialize split page table locks for vector page"
2019-10-14 16:02 [PATCH RT] Revert "ARM: Initialize split page table locks for vector page" Sebastian Andrzej Siewior
@ 2019-10-15 16:26 ` Matthew Wilcox
2019-10-15 16:40 ` Sebastian Andrzej Siewior
0 siblings, 1 reply; 3+ messages in thread
From: Matthew Wilcox @ 2019-10-15 16:26 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-kernel, linux-mm, Frank Rowand, Peter Zijlstra,
Thomas Gleixner, Steven Rostedt
On Mon, Oct 14, 2019 at 06:02:38PM +0200, Sebastian Andrzej Siewior wrote:
> 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.
Did your test build have ALLOC_SPLIT_PTLOCKS defined?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH RT] Revert "ARM: Initialize split page table locks for vector page"
2019-10-15 16:26 ` Matthew Wilcox
@ 2019-10-15 16:40 ` Sebastian Andrzej Siewior
0 siblings, 0 replies; 3+ messages in thread
From: Sebastian Andrzej Siewior @ 2019-10-15 16:40 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-kernel, linux-mm, Frank Rowand, Peter Zijlstra,
Thomas Gleixner, Steven Rostedt
On 2019-10-15 09:26:09 [-0700], Matthew Wilcox wrote:
> Did your test build have ALLOC_SPLIT_PTLOCKS defined?
I tried to explain that ptlock_ptr() returns NULL for the page before
the ctor invocation and non-NULL afterwards which means that
USE_SPLIT_PTE_PTLOCKS and ALLOC_SPLIT_PTLOCKS was defined.
Sebastian
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-10-15 16:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-14 16:02 [PATCH RT] Revert "ARM: Initialize split page table locks for vector page" Sebastian Andrzej Siewior
2019-10-15 16:26 ` Matthew Wilcox
2019-10-15 16:40 ` Sebastian Andrzej Siewior
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.