diff options
| author | Piotr Kubaj <pkubaj@FreeBSD.org> | 2026-09-14 13:13:51 +0000 |
|---|---|---|
| committer | Piotr Kubaj <pkubaj@FreeBSD.org> | 2026-09-14 13:15:48 +0000 |
| commit | 42c69445ca336b13e27e3e5960ace344c64ae0eb (patch) | |
| tree | 70ad5b2ba7156177f884213b326eaa9a7b09f78f /make | |
| parent | 2f10ffc003be396f3fc23cd2888023896560252b (diff) | |
mmu_radix_extract() walks the page tables without holding the pmap lock,
unlike its hash MMU counterpart moea64_extract(). A concurrent unmap can
free and recycle the page table page being walked, so the read returns
whatever now occupies that memory and the caller gets a physical address
that never existed.
That is how mmu_radix_sync_icache() came to hand a bogus address to
__syncicache() and panic the machine. Commit 1574ca1955f5 worked around
it by taking the pmap lock in mmu_radix_sync_icache(), but the machine
independent callers of pmap_extract() - vm_sync_icache(), proc_rwmem()
and the vslock() paths - remain exposed to the same failure.
Rename the existing body to mmu_radix_extract_locked(), which asserts the
lock, and make mmu_radix_extract() a thin wrapper that acquires it.
mmu_radix_sync_icache() already holds the pmap lock, so it calls the
locked variant directly and neither recurses nor reacquires the lock once
per page.
Suggested by: alc
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D59320
Reviewed by: markj, jhibbits
Diffstat (limited to 'make')
0 files changed, 0 insertions, 0 deletions
