diff options
author | Alan Cox <alc@FreeBSD.org> | 2012-03-22 04:52:51 +0000 |
---|---|---|
committer | Alan Cox <alc@FreeBSD.org> | 2012-03-22 04:52:51 +0000 |
commit | 5730afc9b6405f9325dfbbf7164dd6c818191ff5 (patch) | |
tree | 6628d621fc3b1f91d03b83dcd89b48528e3132fe /kerberos5/usr.bin/hxtool | |
parent | bfb2fa9f007481070ebebbb93728b8b3648a5553 (diff) | |
download | src-5730afc9b6405f9325dfbbf7164dd6c818191ff5.tar.gz src-5730afc9b6405f9325dfbbf7164dd6c818191ff5.zip |
Handle spurious page faults that may occur in no-fault sections of the
kernel.
When access restrictions are added to a page table entry, we flush the
corresponding virtual address mapping from the TLB. In contrast, when
access restrictions are removed from a page table entry, we do not
flush the virtual address mapping from the TLB. This is exactly as
recommended in AMD's documentation. In effect, when access
restrictions are removed from a page table entry, AMD's MMUs will
transparently refresh a stale TLB entry. In short, this saves us from
having to perform potentially costly TLB flushes. In contrast,
Intel's MMUs are allowed to generate a spurious page fault based upon
the stale TLB entry. Usually, such spurious page faults are handled
by vm_fault() without incident. However, when we are executing
no-fault sections of the kernel, we are not allowed to execute
vm_fault(). This change introduces special-case handling for spurious
page faults that occur in no-fault sections of the kernel.
In collaboration with: kib
Tested by: gibbs (an earlier version)
I would also like to acknowledge Hiroki Sato's assistance in
diagnosing this problem.
MFC after: 1 week
Notes
Notes:
svn path=/head/; revision=233291
Diffstat (limited to 'kerberos5/usr.bin/hxtool')
0 files changed, 0 insertions, 0 deletions