All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Lorenzo Stoakes <ljs@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Muchun Song <muchun.song@linux.dev>,
	David Hildenbrand <david@kernel.org>,
	Pedro Falcato <pfalcato@suse.de>,
	"Liam R . Howlett" <liam@infradead.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare"
Date: Wed, 13 May 2026 05:21:06 +0200	[thread overview]
Message-ID: <agPuIviEgS-9wWqK@localhost.localdomain> (raw)
In-Reply-To: <20260512160643.266960-1-ljs@kernel.org>

On Tue, May 12, 2026 at 05:06:43PM +0100, Lorenzo Stoakes wrote:
> This reverts commit ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use
> mmap_prepare") with conflict resolution to account for changes in commit
> ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare").
> 
> The patch incorrectly handled hugetlb VMA lock allocation at the
> mmap_prepare stage, where a failed allocation occurring after mmap_prepare
> is called might result in the lock leaking.
> 
> There is no risk of a merge causing a similar issues, as VMA_DONTEXPAND_BIT
> is set for hugetlb mappings.
> 
> As a first step in addressing this issue, simply revert the change so we
> can rework how we do this having corrected the underlying issues.
> 
> We maintain the VMA flags changes as best we can, accounting for the fact
> that we were working with a VMA descriptor previously and propagating
> like-for-like changes for this.
> 
> Note that we invoke vma_set_flags() and do not call vma_start_write() as
> vm_flags_set() does. This is OK as it's being done in an .mmap hook where
> the VMA is not yet linked into the tree so nobody else can be accessing it.
> 
> Fixes: ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare")
> Reported-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
> Closes: https://lore.kernel.org/linux-mm/20260425070700.562229-1-25181214217@stu.xidian.edu.cn/
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>

Acked-by: Oscar Salvador <osalvador@suse.de>


-- 
Oscar Salvador
SUSE Labs


      parent reply	other threads:[~2026-05-13  3:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-12 16:06 [PATCH] Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare" Lorenzo Stoakes
2026-05-13  1:23 ` Muchun Song
2026-05-13  3:21 ` Oscar Salvador [this message]

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=agPuIviEgS-9wWqK@localhost.localdomain \
    --to=osalvador@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=pfalcato@suse.de \
    /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.