On Wed, Feb 24, 2016 at 11:51:47AM +0100, Christian Borntraeger wrote:
On 02/24/2016 11:41 AM, Will Deacon wrote:
quoted
On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
quoted
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