linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: ajay.kaher@broadcom.com,akpm@linux-foundation.org,alexey.makhalov@broadcom.com,bp@alien8.de,dave.hansen@linux.intel.com,gregkh@linuxfoundation.org,hpa@zytor.com,linux-mm@kvack.org,luto@kernel.org,mawupeng1@huawei.com,mingo@redhat.com,oficerovas@altlinux.org,peterz@infradead.org,syzbot+5f488e922d047d8f00cc@syzkaller.appspotmail.com,tapas.kundu@broadcom.com,tglx@linutronix.de,vamsi-krishna.brahmajosyula@broadcom.com,yin.ding@broadcom.com
Cc: <stable-commits@vger.kernel.org>
Subject: Patch "x86/mm/pat: clear VM_PAT if copy_p4d_range failed" has been added to the 6.1-stable tree
Date: Thu, 08 Jan 2026 14:36:39 +0100	[thread overview]
Message-ID: <2026010839-revisable-pasty-a219@gregkh> (raw)
In-Reply-To: <20251224102432.923410-2-ajay.kaher@broadcom.com>


This is a note to let you know that I've just added the patch titled

    x86/mm/pat: clear VM_PAT if copy_p4d_range failed

to the 6.1-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     x86-mm-pat-clear-vm_pat-if-copy_p4d_range-failed.patch
and it can be found in the queue-6.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


From stable+bounces-203368-greg=kroah.com@vger.kernel.org Wed Dec 24 11:43:39 2025
From: Ajay Kaher <ajay.kaher@broadcom.com>
Date: Wed, 24 Dec 2025 10:24:31 +0000
Subject: x86/mm/pat: clear VM_PAT if copy_p4d_range failed
To: stable@vger.kernel.org, gregkh@linuxfoundation.org
Cc: dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ajay.kaher@broadcom.com, alexey.makhalov@broadcom.com, vamsi-krishna.brahmajosyula@broadcom.com, yin.ding@broadcom.com, tapas.kundu@broadcom.com, Ma Wupeng <mawupeng1@huawei.com>, syzbot+5f488e922d047d8f00cc@syzkaller.appspotmail.com, Alexander Ofitserov <oficerovas@altlinux.org>
Message-ID: <20251224102432.923410-2-ajay.kaher@broadcom.com>

From: Ma Wupeng <mawupeng1@huawei.com>

[ Upstream commit d155df53f31068c3340733d586eb9b3ddfd70fc5 ]

Syzbot reports a warning in untrack_pfn().  Digging into the root we found
that this is due to memory allocation failure in pmd_alloc_one.  And this
failure is produced due to failslab.

In copy_page_range(), memory alloaction for pmd failed.  During the error
handling process in copy_page_range(), mmput() is called to remove all
vmas.  While untrack_pfn this empty pfn, warning happens.

Here's a simplified flow:

dup_mm
  dup_mmap
    copy_page_range
      copy_p4d_range
        copy_pud_range
          copy_pmd_range
            pmd_alloc
              __pmd_alloc
                pmd_alloc_one
                  page = alloc_pages(gfp, 0);
                    if (!page)
                      return NULL;
    mmput
        exit_mmap
          unmap_vmas
            unmap_single_vma
              untrack_pfn
                follow_phys
                  WARN_ON_ONCE(1);

Since this vma is not generate successfully, we can clear flag VM_PAT.  In
this case, untrack_pfn() will not be called while cleaning this vma.

Function untrack_pfn_moved() has also been renamed to fit the new logic.

Link: https://lkml.kernel.org/r/20230217025615.1595558-1-mawupeng1@huawei.com
Signed-off-by: Ma Wupeng <mawupeng1@huawei.com>
Reported-by: <syzbot+5f488e922d047d8f00cc@syzkaller.appspotmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Alexander Ofitserov <oficerovas@altlinux.org>
Cc: stable@vger.kernel.org
[ Ajay: Modified to apply on v6.1 ]
Signed-off-by: Ajay Kaher <ajay.kaher@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/mm/pat/memtype.c |   12 ++++++++----
 include/linux/pgtable.h   |    7 ++++---
 mm/memory.c               |    1 +
 mm/mremap.c               |    2 +-
 4 files changed, 14 insertions(+), 8 deletions(-)

--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -1137,11 +1137,15 @@ void untrack_pfn(struct vm_area_struct *
 }
 
 /*
- * untrack_pfn_moved is called, while mremapping a pfnmap for a new region,
- * with the old vma after its pfnmap page table has been removed.  The new
- * vma has a new pfnmap to the same pfn & cache type with VM_PAT set.
+ * untrack_pfn_clear is called if the following situation fits:
+ *
+ * 1) while mremapping a pfnmap for a new region,  with the old vma after
+ * its pfnmap page table has been removed.  The new vma has a new pfnmap
+ * to the same pfn & cache type with VM_PAT set.
+ * 2) while duplicating vm area, the new vma fails to copy the pgtable from
+ * old vma.
  */
-void untrack_pfn_moved(struct vm_area_struct *vma)
+void untrack_pfn_clear(struct vm_area_struct *vma)
 {
 	vma->vm_flags &= ~VM_PAT;
 }
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1214,9 +1214,10 @@ static inline void untrack_pfn(struct vm
 }
 
 /*
- * untrack_pfn_moved is called while mremapping a pfnmap for a new region.
+ * untrack_pfn_clear is called while mremapping a pfnmap for a new region
+ * or fails to copy pgtable during duplicate vm area.
  */
-static inline void untrack_pfn_moved(struct vm_area_struct *vma)
+static inline void untrack_pfn_clear(struct vm_area_struct *vma)
 {
 }
 #else
@@ -1228,7 +1229,7 @@ extern void track_pfn_insert(struct vm_a
 extern int track_pfn_copy(struct vm_area_struct *vma);
 extern void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
 			unsigned long size);
-extern void untrack_pfn_moved(struct vm_area_struct *vma);
+extern void untrack_pfn_clear(struct vm_area_struct *vma);
 #endif
 
 #ifdef CONFIG_MMU
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1335,6 +1335,7 @@ copy_page_range(struct vm_area_struct *d
 			continue;
 		if (unlikely(copy_p4d_range(dst_vma, src_vma, dst_pgd, src_pgd,
 					    addr, next))) {
+			untrack_pfn_clear(dst_vma);
 			ret = -ENOMEM;
 			break;
 		}
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -682,7 +682,7 @@ static unsigned long move_vma(struct vm_
 
 	/* Tell pfnmap has moved from this vma */
 	if (unlikely(vma->vm_flags & VM_PFNMAP))
-		untrack_pfn_moved(vma);
+		untrack_pfn_clear(vma);
 
 	if (unlikely(!err && (flags & MREMAP_DONTUNMAP))) {
 		/* We always clear VM_LOCKED[ONFAULT] on the old vma */


Patches currently in stable-queue which might be from ajay.kaher@broadcom.com are

queue-6.1/usb-xhci-move-link-chain-bit-quirk-checks-into-one-helper-function.patch
queue-6.1/x86-mm-pat-fix-vm_pat-handling-when-fork-fails-in-copy_page_range.patch
queue-6.1/sched-fair-proportional-newidle-balance.patch
queue-6.1/sched-fair-small-cleanup-to-update_newidle_cost.patch
queue-6.1/rdma-core-fix-kasan-slab-use-after-free-read-in-ib_register_device-problem.patch
queue-6.1/x86-mm-pat-clear-vm_pat-if-copy_p4d_range-failed.patch
queue-6.1/drm-vmwgfx-fix-a-null-ptr-access-in-the-cursor-snooper.patch
queue-6.1/sched-fair-small-cleanup-to-sched_balance_newidle.patch
queue-6.1/usb-xhci-apply-the-link-chain-quirk-on-nec-isoc-endpoints.patch


  reply	other threads:[~2026-01-08 13:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-24 10:24 [PATCH v6.1 0/2] x86/mm/pat: fix VM_PAT handling Ajay Kaher
2025-12-24 10:24 ` [PATCH v6.1 1/2] x86/mm/pat: clear VM_PAT if copy_p4d_range failed Ajay Kaher
2026-01-08 13:36   ` gregkh [this message]
2025-12-24 10:24 ` [PATCH v6.1 2/2] x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range() Ajay Kaher
2026-01-08 13:36   ` Patch "x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()" has been added to the 6.1-stable tree gregkh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026010839-revisable-pasty-a219@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=ajay.kaher@broadcom.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexey.makhalov@broadcom.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mawupeng1@huawei.com \
    --cc=mingo@redhat.com \
    --cc=oficerovas@altlinux.org \
    --cc=peterz@infradead.org \
    --cc=stable-commits@vger.kernel.org \
    --cc=syzbot+5f488e922d047d8f00cc@syzkaller.appspotmail.com \
    --cc=tapas.kundu@broadcom.com \
    --cc=tglx@linutronix.de \
    --cc=vamsi-krishna.brahmajosyula@broadcom.com \
    --cc=yin.ding@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox