mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Mark Brown <broonie@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Aishwarya TCV <aishwarya.tcv@arm.com>,
	dev.jain@arm.com
Subject: Re: [PATCH v2 06/10] mm: avoid using vma_merge() for new VMAs
Date: Thu, 29 Aug 2024 22:22:53 +0100	[thread overview]
Message-ID: <9dcddc2c-482b-4e12-a409-eee8d902ba26@lucifer.local> (raw)
In-Reply-To: <51452bab-65ef-4924-8ca8-61536d2bc168@sirena.org.uk>

On Thu, Aug 29, 2024 at 08:46:28PM GMT, Mark Brown wrote:
> On Fri, Aug 23, 2024 at 09:07:01PM +0100, Lorenzo Stoakes wrote:
> > Abstract vma_merge_new_vma() to use vma_merge_struct and rename the
> > resultant function vma_merge_new_range() to be clear what the purpose of
> > this function is - a new VMA is desired in the specified range, and we wish
> > to see if it is possible to 'merge' surrounding VMAs into this range rather
> > than having to allocate a new VMA.
>
> This patch, which is in -next today with the fixup Lorenzo posted as
> commit 8c9d0f8b1e9a42586, seems to be causing problems with the mremap
> expand merge selftest.  The test has been failing for a few days.  It
> unfortunately doesn't log anything about why it's upset:
>
> # # ok 15 5MB mremap - Source 1MB-aligned, Dest 1MB-aligned with 40MB Preamble
> # # not ok 16 mremap expand merge
> # # ok 18 mremap mremap move within range

[snip]

Thanks, I figured out the problem, it's not arm-specific, I was running
self-tests but eyeballing-failure resulted in me missing this.

This is a product of vma_merge_extend() invoking vma_merge_new_range() without
having determined the next VMA correctly, after moving from vma_merge() (which
looked this up for us) to vma_merge_new_range() (which does not).

This is after having adjusted the assumptions between v1 and v2 of the series in
each merge function, and I simply missed this mremap()-specific case.

Andrew - I enclose a fix-patch to get a fix out for this asap, but I am due a
respin relatively soon and will also include that in this.

----8<----
From 3678f8a53f98de52f11946d4d32e6fb239d11c2f Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Thu, 29 Aug 2024 22:18:02 +0100
Subject: [PATCH] mm: correctly determine vmg.next in vma_merge_extend()

vma_merge_next_range() requires that the caller specify prev AND next.

Failure to specify results in missed merges. Fix this by explicitly looking
up next.

This function is explicitly used by mremap() in extend cases.

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reported-by: Mark Brown <broonie@kernel.org>
---
 mm/vma.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/vma.c b/mm/vma.c
index 7cddeea907f8..bd35abc70ed8 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -1489,6 +1489,10 @@ struct vm_area_struct *vma_merge_extend(struct vma_iterator *vmi,
 {
 	VMG_VMA_STATE(vmg, vmi, vma, vma, vma->vm_end, vma->vm_end + delta);

+	vmg.next = vma_next(vmi);
+	if (vma_prev(vmi))
+		vma_iter_next_range(vmi);
+
 	/* We use the VMA to populate VMG fields only. */
 	vmg.vma = NULL;
 	return vma_merge_new_range(&vmg);
--
2.46.0

  reply	other threads:[~2024-08-29 21:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-23 20:06 [PATCH v2 00/10] mm: remove vma_merge() Lorenzo Stoakes
2024-08-23 20:06 ` [PATCH v2 01/10] tools: improve vma test Makefile Lorenzo Stoakes
2024-08-28 19:16   ` Liam R. Howlett
2024-08-23 20:06 ` [PATCH v2 02/10] tools: add VMA merge tests Lorenzo Stoakes
2024-08-28 19:16   ` Liam R. Howlett
2024-08-23 20:06 ` [PATCH v2 03/10] mm: introduce vma_merge_struct and abstract vma_merge(),vma_modify() Lorenzo Stoakes
2024-08-28 19:35   ` Liam R. Howlett
2024-08-30 13:28     ` Lorenzo Stoakes
2024-08-23 20:06 ` [PATCH v2 04/10] mm: remove duplicated open-coded VMA policy check Lorenzo Stoakes
2024-08-28 19:42   ` Liam R. Howlett
2024-08-23 20:07 ` [PATCH v2 05/10] mm: abstract vma_expand() to use vma_merge_struct Lorenzo Stoakes
2024-08-28 20:03   ` Liam R. Howlett
2024-08-23 20:07 ` [PATCH v2 06/10] mm: avoid using vma_merge() for new VMAs Lorenzo Stoakes
2024-08-27 11:41   ` Lorenzo Stoakes
2024-08-28 20:52   ` Liam R. Howlett
2024-08-30 15:19     ` Lorenzo Stoakes
2024-08-29 19:46   ` Mark Brown
2024-08-29 21:22     ` Lorenzo Stoakes [this message]
2024-08-30 12:59       ` Mark Brown
2024-08-30 13:02         ` Lorenzo Stoakes
2024-08-30 13:05           ` Mark Brown
2024-08-30 13:10             ` Lorenzo Stoakes
2024-08-23 20:07 ` [PATCH v2 07/10] mm: make vma_prepare() and friends static and internal to vma.c Lorenzo Stoakes
2024-08-23 20:07 ` [PATCH v2 08/10] mm: introduce commit_merge(), abstracting final commit of merge Lorenzo Stoakes
2024-08-23 20:07 ` [PATCH v2 09/10] mm: refactor vma_merge() into modify-only vma_merge_existing_range() Lorenzo Stoakes
2024-08-23 20:07 ` [PATCH v2 10/10] mm: rework vm_ops->close() handling on VMA merge Lorenzo Stoakes

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=9dcddc2c-482b-4e12-a409-eee8d902ba26@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=aishwarya.tcv@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ryan.roberts@arm.com \
    --cc=vbabka@suse.cz \
    /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

all inboxes | Powered by JetHome®