Page MenuHomeFreeBSD

vm: Change result code for VM_FAULT_NOFILL
Needs ReviewPublic

Authored by freebsdphab-AX9_cmx.ietfng.org on Jun 22 2021, 1:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Nov 26, 2:37 PM
Unknown Object (File)
Mon, Nov 18, 12:56 AM
Unknown Object (File)
Thu, Nov 14, 10:04 PM
Unknown Object (File)
Wed, Nov 13, 2:59 AM
Unknown Object (File)
Tue, Nov 12, 8:20 PM
Unknown Object (File)
Sat, Nov 9, 5:57 PM
Unknown Object (File)
Sat, Nov 9, 5:25 PM
Unknown Object (File)
Sat, Nov 9, 5:07 PM
Subscribers
None

Details

Reviewers
markj
jhb
alc
kib
Summary

At present, a return from vm_fault() of KERN_OUT_OF_BOUNDS can signal a pager failure or can indicate that VM_FAULT_NOFILL was successful in avoiding a fill. As some callers (e.g., the prototype for CHERI capability revocation) may want to distinguish these cases, use a different return code. KERN_NOT_RECEIVER is not otherwise an expected return from vm_fault(), so go ahead and use it (again) as a special case.

The sole existing in-tree user of VM_FAULT_NOFILL seems to be sys/kern/kern_exec.c:/^core_output and that path does not discriminate on return codes beyond KERN_SUCCESS vs. anything else. This change thus does not alter its behaviour.

Test Plan

In use as part of the CHERI capability revocation prototype for a while; better test plans welcome.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

You should either assert that VM_FAULT_NOFILL is not passed to vm_fault_trap(), or do something with KERN_NOT_RECEIVER there.

That said, KERN_NOT_RECEIVER was an internal status for vm_fault.c, and it is cheap to allocate a unique error code for your use, avoiding any collisions.