Page MenuHomeFreeBSD

arm64: Handle translation faults for thread structures
ClosedPublic

Authored by markj on Nov 1 2022, 8:42 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 28, 12:49 PM
Unknown Object (File)
Dec 23 2023, 2:25 AM
Unknown Object (File)
Dec 12 2023, 6:17 AM
Unknown Object (File)
Dec 7 2023, 3:08 PM
Unknown Object (File)
Dec 3 2023, 8:59 AM
Unknown Object (File)
Nov 7 2023, 9:07 AM
Unknown Object (File)
Nov 5 2023, 1:01 AM
Unknown Object (File)
Nov 3 2023, 6:13 PM
Subscribers

Details

Summary

The break-before-make requirement poses a problem when promoting or
demoting mappings containing thread structures: a CPU may raise a
translation fault while accessing curthread, and data_abort() accesses
the thread again before pmap_fault() can translate the address and
return.

Normally this isn't a problem because we have a hack to ensure that
slabs used by the thread zone are always accessed via the direct map,
where promotions and demotions are rare. However, this hack doesn't
work properly with UMA_MD_SMALL_ALLOC disabled, as is the case with
KASAN configured (since our KASAN implementation does not shadow the
direct map and so tries to force the use of the kernel map wherever
possible).

Fix the problem by modifying data_abort() to handle translation faults
in the kernel map without dereferencing "td", i.e., curthread, and
without enabling interrupts. pmap_fault() has special handling for
translation faults which makes it safe to call. Then, revert the
aforementioned hack.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 48113
Build 45000: arc lint + arc unit

Event Timeline

markj requested review of this revision.Nov 1 2022, 8:42 PM
This revision is now accepted and ready to land.Nov 1 2022, 9:10 PM
sys/arm64/arm64/trap.c
294–295

Is there a reason to not call pmap_fault unconditionally here? We could then either add a flag to skip the call later or move it up to the relavant condition blocks.

sys/arm64/arm64/trap.c
294–295

Yes: pmap_fault() may acquire the pmap lock to handle other types of faults, which can't be done while interrupts are disabled. Interrupts have to remain disabled here since handlers might try to dereference curthread.

We could skip a second pmap_fault() call here, but if it fails the first time then won't this likely be a fatal data abort anyway?

sys/arm64/arm64/trap.c
294–295

In that case I think we just use pmap_klookup directly here as all we need to know is if there is a mapping for the virtual address, even if it's currently in a break-before-make sequence.

markj marked 2 inline comments as done.

Use pmap_klookup() directly

This revision now requires review to proceed.Nov 2 2022, 4:53 PM
This revision is now accepted and ready to land.Nov 2 2022, 5:23 PM
alc added inline comments.
sys/arm64/arm64/trap.c
294–295

We could skip a second pmap_fault() call here, but if it fails the first time then won't this likely be a fatal data abort anyway?

I would suggest adding a sentence relating to this, e.g., "In principle, if pmap_klookup() fails, there is no need to call pmap_fault() below, but avoiding that call is not worth the effort."

markj marked an inline comment as done.Nov 2 2022, 5:46 PM