All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: ziy@nvidia.com, liam@infradead.org, hughd@google.com,
	david@kernel.org, akpm@linux-foundation.org,
	nico.pache@linux.dev, dev.jain@arm.com, ryan.roberts@arm.com,
	baohua@kernel.org, usama.arif@linux.dev, ljs@kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: shmem: fix incorrect vm_flags usage when checking allowable orders
Date: Mon, 17 Aug 2026 15:39:35 +0800	[thread overview]
Message-ID: <9255fa58-1fda-48d5-9353-f234fb35b78c@linux.dev> (raw)
In-Reply-To: <ed34ca03ae7d65e89467fb87bc961f5497049c00.1786948410.git.baolin.wang@linux.alibaba.com>



On 2026/8/17 15:16, Baolin Wang wrote:
> Lance reported that when MADV_HUGEPAGE is set on a tmpfs file mounted with
> huge=advise option, khugepaged fails the allowable order check and does not
> scan the tmpfs file for collapse.
> 
> After commit 6beeab870e70 ("mm: shmem: move shmem_huge_global_enabled() into
> shmem_allowable_huge_orders()"), the shmem/tmpfs allowable order check reads
> vma->vm_flags directly.  However, when MADV_HUGEPAGE is handled,
> khugepaged_enter_vma() is called before the VMA's vm_flags have been updated,
> so the check uses stale flags and incorrectly rejects the VMA for collapse.
> As a result, khugepaged does not collapse the tmpfs file into PMD order in time.
> 
> Fix this by passing vm_flags as a parameter to shmem_allowable_huge_orders()
> instead of reading it from the vm_area_struct.
> 
> Reported-by: Lance Yang <lance.yang@linux.dev>
> Closes: https://lore.kernel.org/all/20260815181632.21453-1-lance.yang@linux.dev/
> Fixes: 6beeab870e70 ("mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> ---

LGTM.

Reviewed-by: Lance Yang <lance.yang@linux.dev>


  reply	other threads:[~2026-08-17  7:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17  7:16 [PATCH] mm: shmem: fix incorrect vm_flags usage when checking allowable orders Baolin Wang
2026-08-17  7:39 ` Lance Yang [this message]
2026-08-17  7:40 ` Lorenzo Stoakes (ARM)
2026-08-17  9:34   ` Baolin Wang
2026-08-17 10:54     ` Baolin Wang

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=9255fa58-1fda-48d5-9353-f234fb35b78c@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=hughd@google.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=nico.pache@linux.dev \
    --cc=ryan.roberts@arm.com \
    --cc=usama.arif@linux.dev \
    --cc=ziy@nvidia.com \
    /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.