stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* stable-backporting the VM_PFNMAP TLB flushing fix (b67fbebd4cf9)
@ 2022-08-29 17:35 Jann Horn
  2022-08-29 17:38 ` Linus Torvalds
  0 siblings, 1 reply; 3+ messages in thread
From: Jann Horn @ 2022-08-29 17:35 UTC (permalink / raw)
  To: stable, Security Officers; +Cc: Peter Zijlstra, Will Deacon

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);

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: stable-backporting the VM_PFNMAP TLB flushing fix (b67fbebd4cf9)
  2022-08-29 17:35 stable-backporting the VM_PFNMAP TLB flushing fix (b67fbebd4cf9) Jann Horn
@ 2022-08-29 17:38 ` Linus Torvalds
  2022-08-29 17:39   ` Linus Torvalds
  0 siblings, 1 reply; 3+ messages in thread
From: Linus Torvalds @ 2022-08-29 17:38 UTC (permalink / raw)
  To: Jann Horn; +Cc: stable, Security Officers, Peter Zijlstra, Will Deacon

On Mon, Aug 29, 2022 at 10:36 AM Jann Horn <jannh@google.com> wrote:
>
> A minimal but also completely different fix would be:

Looks sane to me.

                   Linus

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: stable-backporting the VM_PFNMAP TLB flushing fix (b67fbebd4cf9)
  2022-08-29 17:38 ` Linus Torvalds
@ 2022-08-29 17:39   ` Linus Torvalds
  0 siblings, 0 replies; 3+ messages in thread
From: Linus Torvalds @ 2022-08-29 17:39 UTC (permalink / raw)
  To: Jann Horn; +Cc: stable, Security Officers, Peter Zijlstra, Will Deacon

On Mon, Aug 29, 2022 at 10:38 AM Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
>
> On Mon, Aug 29, 2022 at 10:36 AM Jann Horn <jannh@google.com> wrote:
> >
> > A minimal but also completely different fix would be:
>
> Looks sane to me.

Just to clarify: we've fixed things in stable backports differently
from the development kernel before - just make sure that the commit
message mentions what the devel fix was and why the stable fix is
different, and it's all good.

                 Linus

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-08-29 17:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-29 17:35 stable-backporting the VM_PFNMAP TLB flushing fix (b67fbebd4cf9) Jann Horn
2022-08-29 17:38 ` Linus Torvalds
2022-08-29 17:39   ` Linus Torvalds

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).