[PATCH] mm/mremap: enforce the driver's page size on resize and move

[PATCH] mm/mremap: enforce the driver's page size on resize and move

[shao.mingyin]

From: Shao Mingyin <shao.mingyin@zte.com.cn>

mm/mremap: enforce the driver's page size on resize and move

device-dax exposes its mapping granularity through vm_ops->pagesize()
and requires both VMA boundaries to be aligned to it. mremap() checks
may_split() when moving a subrange, but does not validate the new end of
an in-place expansion or both boundaries of the destination VMA.

An unaligned expansion or move can therefore succeed and leave a VMA
that device-dax rejects at fault time with SIGBUS. Check the final
new_addr and new_len before moving, and check vm_end + delta before
expanding in place.

Checking the actual boundaries preserves an expansion starting inside a
VMA when its resulting end remains aligned. The move check also covers
equal-length MREMAP_FIXED moves. Existing PAGE_SIZE mappings pass both
checks, and the existing hugetlb restrictions remain in effect.

Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
---
Build-tested mm/mremap.o with W=1 on x86_64. Earlier QEMU testing used
a synthetic VMA with 2 MiB pagesize and may_split callbacks to compare
unaligned moves/expansions and valid aligned/interior expansions.
No device-dax hardware was used. The synthetic tests do not establish
a real device-dax workload report. No stable tag is included until the
historical introduction and applicable backport baseline are established.


 mm/mremap.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/mm/mremap.c b/mm/mremap.c
index fff0465f5e061ff44ae4fd42bc037ce178517bda..8a0a406bd78d41df96f7ef41aeb6eae36c77c1a6 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -1406,6 +1406,17 @@ static unsigned long move_vma(struct vma_remap_struct *vrm)
 	unsigned long hiwater_vm;
 	int err;
 
+	/*
+	 * A driver can impose a page size larger than PAGE_SIZE through
+	 * vm_ops->pagesize(); device-dax exposes dev_dax->align this way and
+	 * rejects any VMA whose start or end is not a multiple of it.  The
+	 * destination VMA spans [new_addr, new_addr + new_len), so do not
+	 * create it with a boundary the driver would reject.
+	 */
+	if ((vrm->new_addr | vrm->new_len) &
+	    (vma_kernel_pagesize(vrm->vma) - 1))
+		return -EINVAL;
+
 	err = prep_move_vma(vrm);
 	if (err)
 		return err;
@@ -1577,6 +1588,16 @@ static bool vrm_can_expand_in_place(struct vma_remap_struct *vrm)
 	if (!vma_expandable(vrm->vma, vrm->delta))
 		return false;
 
+	/*
+	 * Growing in place only moves the end of the VMA.  A driver page
+	 * size larger than PAGE_SIZE requires the new end to stay aligned;
+	 * otherwise let the caller try a move, where move_vma() validates
+	 * the destination instead.
+	 */
+	if ((vrm->vma->vm_end + vrm->delta) &
+	    (vma_kernel_pagesize(vrm->vma) - 1))
+		return false;
+
 	return true;
 }
 

base-commit: 84abb955b1015477aa11a96e2f3ac1b938b77f48
-- 
2.43.0

Re: [PATCH] mm/mremap: enforce the driver's page size on resize and move

[Lorenzo Stoakes (ARM)]

On Sun, Nov 15, 2026 at 12:47:00AM +0800, shao.mingyin@zte.com.cn wrote:
> From: Shao Mingyin <shao.mingyin@zte.com.cn>
>
> mm/mremap: enforce the driver's page size on resize and move
>
> device-dax exposes its mapping granularity through vm_ops->pagesize()
> and requires both VMA boundaries to be aligned to it. mremap() checks
> may_split() when moving a subrange, but does not validate the new end of
> an in-place expansion or both boundaries of the destination VMA.
>
> An unaligned expansion or move can therefore succeed and leave a VMA
> that device-dax rejects at fault time with SIGBUS. Check the final
> new_addr and new_len before moving, and check vm_end + delta before
> expanding in place.
>
> Checking the actual boundaries preserves an expansion starting inside a
> VMA when its resulting end remains aligned. The move check also covers
> equal-length MREMAP_FIXED moves. Existing PAGE_SIZE mappings pass both
> checks, and the existing hugetlb restrictions remain in effect.
>
> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>

NAK obviously.

This patch is broken, wrong, and it's not even a bug.

Also, you are flooding the kernel with patches, 17 series across 7
subsystems over 23 hrs:

https://lore.kernel.org/all/?q=f%3Ashao.mingyin%40zte.com.cn

Please just go away. Nobody wants your AI slop.

--
Cheers, Lorenzo