summaryrefslogtreecommitdiff
path: root/arch/um
diff options
context:
space:
mode:
authorPalmer Dabbelt <palmer@rivosinc.com>2023-03-09 15:22:05 -0800
committerPalmer Dabbelt <palmer@rivosinc.com>2023-03-09 15:22:05 -0800
commit9b7fef255c80db8fc33fc06f2ad6d8e3ced1389b (patch)
tree1502eff3eb6bb0d198553344e0dac48d64da3cd1 /arch/um
parent2a8db5ec4a28a0fce822d10224db9471a44b6925 (diff)
parent82dd33fde0268cc622d3d1ac64971f3f61634142 (diff)
downloadlwn-9b7fef255c80db8fc33fc06f2ad6d8e3ced1389b.tar.gz
lwn-9b7fef255c80db8fc33fc06f2ad6d8e3ced1389b.zip
Merge patch series "riscv: asid: switch to alternative way to fix stale TLB entries"
Sergey Matyukevich <geomatsi@gmail.com> says: Some time ago two different patches have been posted to fix stale TLB entries that caused applications crashes. The patch [0] suggested 'aggregating' mm_cpumask, i.e. current cpu is not cleared for the switched-out task in switch_mm function. For additional explanations see the commit message by Guo Ren. The same approach is used by arc architecture, so another good comment is for switch_mm in arch/arc/include/asm/mmu_context.h. The patch [1] attempted to reduce the number of TLB flushes by deferring (and possibly avoiding) them for CPUs not running the task. Patch [1] has been merged. However we already have two bug reports from different vendors. So apparently something is missing in the approach suggested in [1]. In both cases the patch [0] fixed the issue. This patch series reverts [1] and replaces it by [0]. [0] https://lore.kernel.org/linux-riscv/20221111075902.798571-1-guoren@kernel.org/ [1] https://lore.kernel.org/linux-riscv/20220829205219.283543-1-geomatsi@gmail.com/ * b4-shazam-merge: riscv: asid: Fixup stale TLB entry cause application crash Revert "riscv: mm: notify remote harts about mmu cache updates" Link: https://lore.kernel.org/r/20230226150137.1919750-1-geomatsi@gmail.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Diffstat (limited to 'arch/um')
0 files changed, 0 insertions, 0 deletions