linux-kernel - Re: [PATCH v3 4/7] mm/mremap: initial refactor of move

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b2fb6b9c-376d-4e9b-905e-26d847fd3865@lucifer.local>
Date: Sun, 30 Mar 2025 17:52:29 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Harry Yoo <harry.yoo@...cle.com>, Yosry Ahmed <yosry.ahmed@...ux.dev>,
        Oliver Sang <oliver.sang@...el.com>, Yi Lai <yi1.lai@...ux.intel.com>
Subject: Re: [PATCH v3 4/7] mm/mremap: initial refactor of move_vma()

On Mon, Mar 10, 2025 at 08:50:37PM +0000, Lorenzo Stoakes wrote:
> Update move_vma() to use the threaded VRM object, de-duplicate code and
> separate into smaller functions to aid readability and debug-ability.
>
> This in turn allows further simplification of expand_vma() as we can
> simply thread VRM through the function.

[snip]

Andrew - I enclose a fix-patch for the issue kindly reported in [0] by Yi
Lai. Since you've not sent the PR to Linus yet maybe you could squash this
in? Otherwise obviously one for 6.15-rc1.

I've tested against the repro and confirm it fixes it, also the fix is
'obvious' as is the cause. I have replied to [0] with an explanation there
also inline.

Apologies for missing this before!

Thanks, Lorenzo

[0]: https://lore.kernel.org/linux-mm/Z+lcvEIHMLiKVR1i@ly-workstation/

----8<----
>From 3709f42feb30e2cfe2f39527d4cd8c74a9e8b724 Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Date: Sun, 30 Mar 2025 17:20:48 +0100
Subject: [PATCH] mm/mremap: do not set vrm->vma NULL immediately prior to
 checking it

This seems rather unwise. If we cannot merge, extend, then we need to
recall the original VMA to see if we need to uncharge.

If we do need to, do so.

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>

---
 mm/mremap.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/mremap.c b/mm/mremap.c
index 0865387531ed..7db9da609c84 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -1561,11 +1561,12 @@ static unsigned long expand_vma_in_place(struct vma_remap_struct *vrm)
 	 * adjacent to the expanded vma and otherwise
 	 * compatible.
 	 */
-	vma = vrm->vma = vma_merge_extend(&vmi, vma, vrm->delta);
+	vma = vma_merge_extend(&vmi, vma, vrm->delta);
 	if (!vma) {
 		vrm_uncharge(vrm);
 		return -ENOMEM;
 	}
+	vrm->vma = vma;

 	vrm_stat_account(vrm, vrm->delta);

--
2.49.0