Excerpts from Linus Torvalds's message of July 28, 2020 4:37 am: > [ Adding linux-arch, just to make other architectures aware of this issue too. > > We have a "flush_tlb_fix_spurious_fault()" thing to take care of the > "TLB may contain stale entries, we can't take the same fault over and > over again" situation. > > On x86, it's a no-op, because x86 doesn't do that. x86 will re-walk > the page tables - or possibly just always invalidate the faulting TLB > entry - before taking a fault, so there can be no long-term stale > TLB's. [snip] > It looks like powerpc people at least thought about this, and only > do it if there is a coprocessor. Which sounds a bit confused, but I > don't know the rules. I'm not sure about ppc32 and 64e, I'm almost certain they should do a local flush if anyting, and someone with a good understanding of the ISAs and CPUs might be able to nop it entirely. I agree global can't ever really make sense (except as a default because we have no generic local flush). powerpc/64s reloads translations after taking a fault, so it's fine with a nop here. The quirk is a problem with coprocessor where it's supposed to invalidate the translation after a fault but it doesn't, so we can get a read-only TLB stuck after something else does a RO->RW upgrade on the TLB. Something like that IIRC. Coprocessors have their own MMU which lives in the nest not the core, so you need a global TLB flush to invalidate that thing. Thanks, Nick
