aboutsummaryrefslogtreecommitdiff
path: root/sbin/mdmfs
diff options
context:
space:
mode:
authorJustin Hibbits <jhibbits@FreeBSD.org>2019-11-01 02:55:58 +0000
committerJustin Hibbits <jhibbits@FreeBSD.org>2019-11-01 02:55:58 +0000
commit8b079fcca72eb48c237fbb705cf00689c3e1dcf4 (patch)
tree0873a66474173d82cb4bbadfc40fefd8057aaf6d /sbin/mdmfs
parentca64a75edafa6a523abad69154da09950a9a16f3 (diff)
downloadsrc-8b079fcca72eb48c237fbb705cf00689c3e1dcf4.tar.gz
src-8b079fcca72eb48c237fbb705cf00689c3e1dcf4.zip
powerpc/booke: Fix TLB1 entry accounting
It's possible, with per-CPU mappings, for TLB1 indices to get out of sync. This presents a problem when trying to insert an entry into TLB1 of all CPUs. Currently that's done by assuming (hoping) that the TLBs are perfectly synced, and inserting to the same index for all CPUs. However, with aforementioned private mappings, this can result in overwriting mappings on the other CPUs. An example: CPU0 CPU1 <setup all mappings> <idle> 3 private mappings kick off CPU 1 initialize shared mappings (3 indices low) Load kernel module, triggers 20 new mappings Sync mappings at N-3 initialize 3 private mappings. At this point, CPU 1 has all the correct mappings, while CPU 0 is missing 3 mappings that were shared across to CPU 1. When CPU 0 tries to access memory in one of the overwritten mappings, it hangs while tripping through the TLB miss handler. Device mappings are not stored in any page table. This fixes by introducing a '-1' index for tlb1_write_entry_int(), so each CPU searches for an available index private to itself. MFC after: 3 weeks
Notes
Notes: svn path=/head/; revision=354235
Diffstat (limited to 'sbin/mdmfs')
0 files changed, 0 insertions, 0 deletions