On Tue, Jul 28, 2020 at 2:39 AM Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
>
> Possibly, as long as any other optimisations only defer the TLB flushing
> for relatively short time (the fault is transient, it will get a
> broadcast TLBI eventually).
I think that in all normal cases, you will have always gotten the TLB
flush by the time the fault handler has gotten either the mmap lock
for reading, or the page table lock for writing.
So by the time we hit the "oh, spurious fault", I _think_ all the
normal paths will have already flushed.
My main worry would be
(a) bugs
(b) some special path that doesn't flush at all, because it knows it
is only loosening restrictions
As mentioned, I do have dim memories of us doing (b) on purpose, but I
can't find it.
I do find:
- instantiating new page table entries without flushing (because we
assume that the TLB does not cache non-present entries), ie
/* No need to invalidate - it was non-present before */
update_mmu_cache(vma, vmf->address, vmf->pte);
- various cases of
if (ptep_set_access_flags(..))
update_mmu_cache(..);
where the code basically has handed the decision over to the
architecture code.
but if you think those cases are ok on arm, then I think you can do
what x86 does and just make it a no-op.
Linus
