All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "Andrew Morton" <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	"Vlastimil Babka" <vbabka@kernel.org>,
	"Jann Horn" <jannh@google.com>,
	"Pedro Falcato" <pfalcato@suse.de>,
	"Jakub Matěna" <matenajakub@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 Luiz Capitulino <luizcap@redhat.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] mm/vma: fix expansion of VMA_MIXEDMAP_BIT VMAs
Date: Fri, 23 Oct 2026 18:30:58 +0100	[thread overview]
Message-ID: <atuY-n02IWHY7SOT@gremlin> (raw)
In-Reply-To: <20261023-vma-expansion-fix-v1-1-6142baf1f46b@kernel.org>

On Fri, Oct 23, 2026 at 04:17:31PM +0100, Lorenzo Stoakes (ARM) wrote:
> Commit ca3d76b0aa80 ("mm: add merging after mremap resize") combined
> merging with expansion of mremap()'d VMAs, however it also unintentionally
> disallowed the expansion of unmergeable VMAs.
>
> Previously it was possible to expand a mixed mapping which mremap() had
> already ensured was a legal expansion.
>
> This is clearly seen in the mremap() logic, as it checks
> vma_is_fixed_mapping() to determine legality of an expansion rather than
> vma_can_merge().
>
> Additionally, copy_vma() allows for a failed merge to result in a new VMA
> being instantiated if MREMAP_MAYMOVE is specified.
>
> However, this is not attempted, as a failure in vma_merge_extend() is
> assumed to be an -ENOMEM failure.

Just to note that VMA_MIXEDMAP_BIT VMAs can _currently_ be expanded if not
attempted to be expanded in-place (e.g. MREMAP_FIXED, or if not enough space to
expand into).

So this patch doesn't re-add the ability to do that per se, it just fixes one
specific means of doing what is already a valid operation.

VMA_MIXEDMAP _expanding_ isn't really a problem - if no fault handler is
installed, faults in the expanded region will SIGBUS, and if one exists it'll be
invoked correctly.

This doesn't work for VMA_PFNMAP_BIT because the page offset might be co-opted
for CoW (!) and thus is unreliable.

And it seems some users do, at least in theory, require it, even if they are
using older kernel revisions :)

> Since vma_merge_extend() is used exclusively by mremap() to perform a merge
> and/or expansion, resolve the issue by invoking vma_expand() for
> unmergeable VMAs there.
>
> Explicitly assert that the VMA is both non-fixed and a mixed mapping.
> This provides double insurance against broken changes in future.
>
> Note that khugepaged_enter_vma() (which vma_merge_new_range() runs) is
> redundant in this case, as a mixed mapping is not subject to khugepaged.
>
> Also update the VMA userland tests to add a required predicate.
>
> Reported-by: Luiz Capitulino <luizcap@redhat.com>
> Closes: https://lore.kernel.org/all/20261023023106.515365-1-luizcap@redhat.com/
> Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize")
> Cc: stable@vger.kernel.org
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> Confirmed that this fixes the repro and passes mm selftests and the VMA
> userland tests.

--
Cheers, Lorenzo


  reply	other threads:[~2026-10-23 17:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-23 15:17 [PATCH] mm/vma: fix expansion of VMA_MIXEDMAP_BIT VMAs Lorenzo Stoakes (ARM)
2026-10-23 17:30 ` Lorenzo Stoakes (ARM) [this message]
2026-10-23 18:11 ` Luiz Capitulino
2026-10-26 13:37   ` Lorenzo Stoakes (ARM)
2026-10-26 13:14 ` Vlastimil Babka (SUSE)
2026-10-26 13:28 ` Pedro Falcato

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=atuY-n02IWHY7SOT@gremlin \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luizcap@redhat.com \
    --cc=matenajakub@gmail.com \
    --cc=pfalcato@suse.de \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@kernel.org \
    /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.