On Wed, Feb 24, 2016 at 11:51:47AM +0100, Christian Borntraeger wrote: > On 02/24/2016 11:41 AM, Will Deacon wrote: > > On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote: > >> Without that fix we would clearly have stale tlb entries, no? > > > > Yes, but AFAIU the sequence on arm64 is: > > > > 1. trans huge mapping (block mapping in arm64 speak) > > 2. faulting entry (pmd_mknotpresent) > > 3. tlb invalidation > > 4. table entry mapping the same pages as (1). > > > > so if the microarchitecture we're on can tolerate a mixture of block > > mappings and page mappings mapping the same VA to the same PA, then the > > lack of TLB maintenance would go unnoticed. There are certainly systems > > where that could cause an issue, but I believe the one I've been testing > > on would be ok. > > So in essence you say it does not matter that you flush the wrong range in > flush_pmd_tlb_range as long as it will be flushed later on when the pages > really go away. Yes, then it really might be ok for arm64. Indeed, although that's a property of the microarchitecture I'm using rather than an architectural guarantee so the code should certainly be fixed! Will -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
