From: Muchun Song <muchun.song@linux.dev>
To: Qi Zheng <qi.zheng@linux.dev>
Cc: osalvador@suse.de, David Hildenbrand <david@kernel.org>,
akpm@linux-foundation.org, azpijr@gmail.com,
Lance Yang <lance.yang@linux.dev>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Qi Zheng <zhengqi.arch@bytedance.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v4 2/3] mm: gup: allow long-term pins of CMA-allocated HugeTLB folios
Date: Wed, 11 Nov 2026 15:42:56 +0800 [thread overview]
Message-ID: <80FED512-77D2-4D49-BAE5-745CE1F711CA@linux.dev> (raw)
In-Reply-To: <503c9f6d869e3206c6fd591de962c3d619b73825.1794379433.git.zhengqi.arch@bytedance.com>
> On Nov 11, 2026, at 14:46, Qi Zheng <qi.zheng@linux.dev> wrote:
>
> From: Qi Zheng <zhengqi.arch@bytedance.com>
>
> Long-term pinning treats explicitly CMA-allocated HugeTLB folios as
> unpinnable, causing unnecessary migration or pinning failures.
>
> These folios already own their CMA bitmap ranges, and memory blocks
Commit message needs updating to bitmap as well.
> overlapping CMA areas cannot be offlined. Allow HugeTLB folios with
> HPG_cma to be pinned directly, including in ZONE_MOVABLE.
>
> Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
> Cc: stable@vger.kernel.org
> Suggested-by: Muchun Song <muchun.song@linux.dev>
> Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
> Acked-by: Muchun Song <muchun.song@linux.dev>
> Reviewed-by: Oscar Salvador <osalvador@suse.de>
> Reviewed-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
> ---
> include/linux/mm.h | 29 +----------------------------
> mm/gup.c | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 32 insertions(+), 28 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b0da9be413098..47d1d96bfc7fd 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2954,35 +2954,8 @@ static inline bool is_zero_folio(const struct folio *folio)
> return is_zero_page(&folio->page);
> }
>
> -/* MIGRATE_CMA and ZONE_MOVABLE do not allow pin folios */
> #ifdef CONFIG_MIGRATION
> -static inline bool folio_is_longterm_pinnable(struct folio *folio)
I think David prefer to move this function first, then fix it in a separate patch,
right?
Thanks,
Muchun
> -{
> -#ifdef CONFIG_CMA
> - int mt = folio_migratetype(folio);
> -
> - if (mt == MIGRATE_CMA || mt == MIGRATE_ISOLATE)
> - return false;
> -#endif
> - /* The zero page can be "pinned" but gets special handling. */
> - if (is_zero_folio(folio))
> - return true;
> -
> - /* Coherent device memory must always allow eviction. */
> - if (folio_is_device_coherent(folio))
> - return false;
> -
> - /*
> - * Filesystems can only tolerate transient delays to truncate and
> - * hole-punch operations
> - */
> - if (folio_is_fsdax(folio))
> - return false;
> -
> - /* Otherwise, non-movable zone folios can be pinned. */
> - return !folio_is_zone_movable(folio);
> -
> -}
> +bool folio_is_longterm_pinnable(struct folio *folio);
> #else
> static inline bool folio_is_longterm_pinnable(struct folio *folio)
> {
> diff --git a/mm/gup.c b/mm/gup.c
> index ebbfee09b7278..fdafc5a1b78ed 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2219,6 +2219,37 @@ struct page *get_dump_page(unsigned long addr, int *locked)
>
> #ifdef CONFIG_MIGRATION
>
> +bool folio_is_longterm_pinnable(struct folio *folio)
> +{
> +#ifdef CONFIG_CMA
> + int mt = folio_migratetype(folio);
> +
> + /* These HugeTLB folios own the CMA memory, so they can be long-term pinned. */
> + if (folio_test_hugetlb(folio) && folio_test_hugetlb_cma(folio))
> + return true;
> +
> + if (mt == MIGRATE_CMA || mt == MIGRATE_ISOLATE)
> + return false;
> +#endif
> + /* The zero page can be "pinned" but gets special handling. */
> + if (is_zero_folio(folio))
> + return true;
> +
> + /* Coherent device memory must always allow eviction. */
> + if (folio_is_device_coherent(folio))
> + return false;
> +
> + /*
> + * Filesystems can only tolerate transient delays to truncate and
> + * hole-punch operations
> + */
> + if (folio_is_fsdax(folio))
> + return false;
> +
> + /* Otherwise, non-movable zone folios can be pinned. */
> + return !folio_is_zone_movable(folio);
> +}
> +
> /*
> * An array of either pages or folios ("pofs"). Although it may seem tempting to
> * avoid this complication, by simply interpreting a list of folios as a list of
> --
> 2.54.0
>
next prev parent reply other threads:[~2026-11-11 7:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 6:46 [PATCH v4 0/3] mm: hugetlb: fix CMA-related issues Qi Zheng
2026-11-11 6:46 ` [PATCH v4 1/3] x86: hugetlb: disable default CMA reservations on 32-bit kernel Qi Zheng
2026-11-11 6:46 ` [PATCH v4 2/3] mm: gup: allow long-term pins of CMA-allocated HugeTLB folios Qi Zheng
2026-11-11 7:42 ` David Hildenbrand (Arm)
2026-11-11 7:42 ` Muchun Song [this message]
2026-11-12 6:13 ` Qi Zheng
2026-11-12 8:49 ` David Hildenbrand (Arm)
2026-11-12 9:04 ` Qi Zheng
2026-11-11 6:46 ` [PATCH v4 3/3] mm: hugetlb: fix GFP mask propagation to CMA Qi Zheng
2026-11-12 11:27 ` Kefeng Wang
2026-11-12 11:30 ` Kefeng Wang
2026-11-13 2:30 ` Qi Zheng
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=80FED512-77D2-4D49-BAE5-745CE1F711CA@linux.dev \
--to=muchun.song@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=azpijr@gmail.com \
--cc=david@kernel.org \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osalvador@suse.de \
--cc=qi.zheng@linux.dev \
--cc=stable@vger.kernel.org \
--cc=zhengqi.arch@bytedance.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.