All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.