Thread (15 messages) 15 messages, 2 authors, 2025-03-24

Re: [PATCH 00/11] Always call constructor for kernel page tables

From: Ryan Roberts <ryan.roberts@arm.com>
Date: 2025-03-17 15:30:55
Also in: linux-arch, linux-arm-kernel, linux-m68k, linux-mm, linux-riscv, linux-s390, lkml, sparclinux

On 17/03/2025 14:16, Kevin Brodsky wrote:
The complications in those special pgtable allocators beg the question:
does it really make sense to treat efi_mm and init_mm differently in
e.g. apply_to_pte_range()? Maybe what we really need is a way to tell if
an mm corresponds to user memory or not, and never use split locks for
non-user mm's. Feedback and suggestions welcome!
The difference in treatment is whether or not the ptl is taken, right? So the
real question is when calling apply_to_pte_range() for efi_mm, is there already
a higher level serialization mechanism that prevents racy accesses? For init_mm,
I think this is handled implicitly because there is no way for user space to
cause apply_to_pte_range() for an arbitrary piece of kernel memory. Although I
can't even see where apply_to_page_range() is called for efi_mm.

FWIW, contpte.c has mm_is_user() which is used by arm64.

Thanks,
Ryan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help