stable-backporting the VM_PFNMAP TLB flushing fix (b67fbebd4cf9)

From: Jann Horn <jannh@google.com>
To: stable <stable@vger.kernel.org>, Security Officers <security@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>, Will Deacon <will@kernel.org>
Subject: stable-backporting the VM_PFNMAP TLB flushing fix (b67fbebd4cf9)
Date: Mon, 29 Aug 2022 19:35:47 +0200	[thread overview]
Message-ID: <CAG48ez3SEqOPcPCYGHVZv4iqEApujD5VtM3Re-tCKLDEFdEdbg@mail.gmail.com> (raw)

commit b67fbebd4cf9 ("mmu_gather: Force tlb-flush VM_PFNMAP vmas")
fixes a TLB flushing bug that probably affects some x86 graphics
drivers, although hitting the bug might be fairly gnarly. Still, it'd
probably be a bad idea to leave it unfixed in the stable kernels that
things like Debian stable rely on.

Unfortunately the way the fix is written, it relies on refactoring
prep work in the three preceding commits, and trying to apply those to
older kernels will result in a bunch of merge conflicts.

Would it be acceptable here to fix the issue in a completely different
way in stable to minimize merge conflicts? Or should the refactoring
prep work and the fix commit all be backported?

A minimal but also completely different fix would be:

diff --git a/mm/mmap.c b/mm/mmap.c
index a50042918cc7..c453a1274305 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2665,6 +2665,18 @@ static void unmap_region(struct mm_struct *mm,
        tlb_gather_mmu(&tlb, mm, start, end);
        update_hiwater_rss(mm);
        unmap_vmas(&tlb, vma, start, end);
+
+       /*
+        * Ensure we have no stale TLB entries by the time this mapping is
+        * removed from the rmap.
+        * Note that we don't have to worry about nested flushes here because
+        * we're holding the mm semaphore for removing the mapping - so any
+        * concurrent flush in this region has to be coming through the rmap,
+        * and we synchronize against that using the rmap lock.
+        */
+       if ((vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) != 0)
+               tlb_flush_mmu(&tlb);
+
        free_pgtables(&tlb, vma, prev ? prev->vm_end : FIRST_USER_ADDRESS,
                                 next ? next->vm_start : USER_PGTABLES_CEILING);
        tlb_finish_mmu(&tlb, start, end);
