On Thu, 2012-06-28 at 20:39 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2012-06-28 at 10:16 +0100, Catalin Marinas wrote: > > That's definitely an issue on ARM and it was hit on older kernels. > > Basically ARM processors can cache any page translation level in the > > TLB. We need to make sure that no page entry at any level (either cached > > in the TLB or not) points to an invalid next level table (hence the TLB > > shootdown). For example, in cases like free_pgd_range(), if the cached > > pgd entry points to an already freed pud/pmd table (pgd_clear is not > > enough) it may walk the page tables speculatively cache another entry in > > the TLB. Depending on the random data it reads from an old table page, > > it may find a global entry (it's just a bit in the pte) which is not > > tagged with an ASID (application specific id). A latter flush_tlb_mm() > > only flushes the current ASID and doesn't touch global entries (used > > only by kernel mappings). So we end up with global TLB entry in user > > space that overrides any other application mapping. > > Right, that's the typical scenario. I haven't looked at your flush > implementation though, but surely you can defer the actual freeing so > you can batch them & limit the number of TLB flushes right ? Yes they do.. its just the up-front TLB invalidate for fullmm that's a problem. s390 really wants this so it can avoid the per pte invalidate otherwise required by ptep_get_and_clear_full(). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href