diff options
author | Palmer Dabbelt <palmer@rivosinc.com> | 2023-03-09 15:22:05 -0800 |
---|---|---|
committer | Palmer Dabbelt <palmer@rivosinc.com> | 2023-03-09 15:22:05 -0800 |
commit | 9b7fef255c80db8fc33fc06f2ad6d8e3ced1389b (patch) | |
tree | 1502eff3eb6bb0d198553344e0dac48d64da3cd1 /arch/um | |
parent | 2a8db5ec4a28a0fce822d10224db9471a44b6925 (diff) | |
parent | 82dd33fde0268cc622d3d1ac64971f3f61634142 (diff) | |
download | lwn-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