[PATCH v2 00/23] arch: allow pte_offset_map[_lock]() to fail
Hugh Dickins
hughd at google.com
Thu Jun 8 12:07:36 PDT 2023
Here is v2 series of patches to various architectures, based on v6.4-rc5:
preparing for v2 of changes following in mm, affecting pte_offset_map()
and pte_offset_map_lock(). There are very few differences from v1:
noted patch by patch below.
v1 was "arch: allow pte_offset_map[_lock]() to fail"
https://lore.kernel.org/linux-mm/77a5d8c-406b-7068-4f17-23b7ac53bc83@google.com/
series of 23 posted on 2023-05-09,
followed by "mm: allow pte_offset_map[_lock]() to fail"
https://lore.kernel.org/linux-mm/68a97fbe-5c1e-7ac6-72c-7b9c6290b370@google.com/
series of 31 posted on 2023-05-21,
followed by "mm: free retracted page table by RCU"
https://lore.kernel.org/linux-mm/35e983f5-7ed3-b310-d949-9ae8b130cdab@google.com/
series of 12 posted on 2023-05-28.
The first two series are "independent": neither depends
for build or correctness on the other, and the arch patches can either be
merged separately via arch trees, or be picked up by akpm; but both series
must be in before the third series is added to make the effective changes
(and that adds just a little more in arm, powerpc, s390 and sparc).
What is it all about? Some mmap_lock avoidance i.e. latency reduction.
Initially just for the case of collapsing shmem or file pages to THPs;
but likely to be relied upon later in other contexts e.g. freeing of
empty page tables (but that's not work I'm doing). mmap_write_lock
avoidance when collapsing to anon THPs? Perhaps, but again that's not
work I've done: a quick attempt was not as easy as the shmem/file case.
I would much prefer not to have to make these small but wide-ranging
changes for such a niche case; but failed to find another way, and
have heard that shmem MADV_COLLAPSE's usefulness is being limited by
that mmap_write_lock it currently requires.
These changes (though of course not these exact patches, and not all
of these architectures!) have been in Google's data centre kernel for
three years now: we do rely upon them.
What are the per-arch changes about? Generally, two things.
One: the current mmap locking may not be enough to guard against that
tricky transition between pmd entry pointing to page table, and empty
pmd entry, and pmd entry pointing to huge page: pte_offset_map() will
have to validate the pmd entry for itself, returning NULL if no page
table is there. What to do about that varies: often the nearby error
handling indicates just to skip it; but in some cases a "goto again"
looks appropriate (and if that risks an infinite loop, then there
must have been an oops, or pfn 0 mistaken for page table, before).
Deeper study of each site might show that 90% of them here in arch
code could only fail if there's corruption e.g. a transition to THP
would be surprising on an arch without HAVE_ARCH_TRANSPARENT_HUGEPAGE.
But given the likely extension to freeing empty page tables, I have
not limited this set of changes to THP; and it has been easier, and
sets a better example, if each site is given appropriate handling.
Two: pte_offset_map() will need to do an rcu_read_lock(), with the
corresponding rcu_read_unlock() in pte_unmap(). But most architectures
never supported CONFIG_HIGHPTE, so some don't always call pte_unmap()
after pte_offset_map(), or have used userspace pte_offset_map() where
pte_offset_kernel() is more correct. No problem in the current tree,
but a problem once an rcu_read_unlock() will be needed to keep balance.
A common special case of that comes in arch/*/mm/hugetlbpage.c, if
the architecture supports hugetlb pages down at the lowest PTE level.
huge_pte_alloc() uses pte_alloc_map(), but generic hugetlb code does
no corresponding pte_unmap(); similarly for huge_pte_offset().
Thanks to Mike Kravetz and Andrew Morton, v6.4-rc1 already provides
pte_alloc_huge() and pte_offset_huge() to help fix up those cases.
This posting is based on v6.4-rc5, but good for any v6.4-rc,
current mm-everything and linux-next.
01/23 arm: allow pte_offset_map[_lock]() to fail
v2: same as v1
02/23 arm64: allow pte_offset_map() to fail
v2: add ack from Catalin
03/23 arm64/hugetlb: pte_alloc_huge() pte_offset_huge()
v2: add ack from Catalin
04/23 ia64/hugetlb: pte_alloc_huge() pte_offset_huge()
v2: same as v1
05/23 m68k: allow pte_offset_map[_lock]() to fail
v2: same as v1
06/23 microblaze: allow pte_offset_map() to fail
v2: same as v1
07/23 mips: update_mmu_cache() can replace __update_tlb()
v2: same as v1
08/23 parisc: add pte_unmap() to balance get_ptep()
v2: typo fix from Helge; stronger commit message
09/23 parisc: unmap_uncached_pte() use pte_offset_kernel()
v2: same as v1
10/23 parisc/hugetlb: pte_alloc_huge() pte_offset_huge()
v2: same as v1
11/23 powerpc: kvmppc_unmap_free_pmd() pte_offset_kernel()
v2: same as v1
12/23 powerpc: allow pte_offset_map[_lock]() to fail
v2: same as v1
13/23 powerpc/hugetlb: pte_alloc_huge()
v2: same as v1
14/23 riscv/hugetlb: pte_alloc_huge() pte_offset_huge()
v2: add review from Alex, ack from Palmer
15/23 s390: allow pte_offset_map_lock() to fail
v2: add comment for Claudio
16/23 s390: gmap use pte_unmap_unlock() not spin_unlock()
v2: add ack from Alexander
17/23 sh/hugetlb: pte_alloc_huge() pte_offset_huge()
v2: same as v1
18/23 sparc/hugetlb: pte_alloc_huge() pte_offset_huge()
v2: same as v1
19/23 sparc: allow pte_offset_map() to fail
v2: same as v1
20/23 sparc: iounit and iommu use pte_offset_kernel()
v2: same as v1
21/23 x86: Allow get_locked_pte() to fail
v2: add WARN_ON_ONCE from PeterZ
22/23 x86: sme_populate_pgd() use pte_offset_kernel()
v2: same as v1
23/23 xtensa: add pte_unmap() to balance pte_offset_map()
v2: stronger commit message
arch/arm/lib/uaccess_with_memcpy.c | 3 ++
arch/arm/mm/fault-armv.c | 5 +++-
arch/arm/mm/fault.c | 3 ++
arch/arm64/mm/fault.c | 3 ++
arch/arm64/mm/hugetlbpage.c | 11 ++-----
arch/ia64/mm/hugetlbpage.c | 4 +--
arch/m68k/include/asm/mmu_context.h | 6 ++--
arch/m68k/kernel/sys_m68k.c | 2 ++
arch/m68k/mm/mcfmmu.c | 52 +++++++++++++--------------------
arch/microblaze/kernel/signal.c | 5 ++--
arch/mips/include/asm/pgtable.h | 15 ++--------
arch/mips/mm/tlb-r3k.c | 5 ++--
arch/mips/mm/tlb-r4k.c | 9 ++----
arch/parisc/kernel/cache.c | 26 +++++++++++++----
arch/parisc/kernel/pci-dma.c | 2 +-
arch/parisc/mm/hugetlbpage.c | 4 +--
arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
arch/powerpc/mm/book3s64/hash_tlb.c | 4 +++
arch/powerpc/mm/book3s64/subpage_prot.c | 2 ++
arch/powerpc/mm/hugetlbpage.c | 2 +-
arch/powerpc/xmon/xmon.c | 5 +++-
arch/riscv/mm/hugetlbpage.c | 4 +--
arch/s390/kernel/uv.c | 2 ++
arch/s390/mm/gmap.c | 31 ++++++++++++--------
arch/s390/mm/pgtable.c | 12 ++++++--
arch/sh/mm/hugetlbpage.c | 4 +--
arch/sparc/kernel/signal32.c | 2 ++
arch/sparc/mm/fault_64.c | 3 ++
arch/sparc/mm/hugetlbpage.c | 4 +--
arch/sparc/mm/io-unit.c | 2 +-
arch/sparc/mm/iommu.c | 2 +-
arch/sparc/mm/tlb.c | 2 ++
arch/x86/kernel/ldt.c | 6 ++--
arch/x86/mm/mem_encrypt_identity.c | 2 +-
arch/xtensa/mm/tlb.c | 5 +++-
35 files changed, 146 insertions(+), 105 deletions(-)
Hugh
More information about the linux-riscv
mailing list