From: Qi Zheng <qi.zheng@linux.dev>
To: "David Hildenbrand (Arm)" <david@kernel.org>,
Muchun Song <muchun.song@linux.dev>
Cc: osalvador@suse.de, akpm@linux-foundation.org, azpijr@gmail.com,
Lance Yang <lance.yang@linux.dev>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
stable@vger.kernel.org, Qi Zheng <zhengqi.arch@bytedance.com>
Subject: Re: [PATCH v4 2/3] mm: gup: allow long-term pins of CMA-allocated HugeTLB folios
Date: Thu, 12 Nov 2026 17:04:28 +0800 [thread overview]
Message-ID: <cc8c4c79-e7b4-46f7-b8a2-b5564b3cc85a@linux.dev> (raw)
In-Reply-To: <ceb2ef49-69e8-425c-9582-ba6fb872e0cf@kernel.org>
On 11/12/26 4:49 PM, David Hildenbrand (Arm) wrote:
> On 11/12/26 07:13, Qi Zheng wrote:
>>
>>
>> On 11/11/26 3:42 PM, Muchun Song 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.
>>
>> Will do.
>>
>>>
>>>> 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?
>>
>> Hi David, is this what you mean? If so, I will split it into two patches
>> for the v5.
>
> Let's try something that is more future-directed: cma should deal with
> cma details. In the future we might implement something reasonable there.
Aha, that does make more sense. Will do.
Thanks,
Qi
>
> diff --git a/include/linux/cma.h b/include/linux/cma.h
> index 8555d38a97b1a..d829fd0355bae 100644
> --- a/include/linux/cma.h
> +++ b/include/linux/cma.h
> @@ -21,6 +21,9 @@
> #define CMA_MIN_ALIGNMENT_BYTES (PAGE_SIZE * CMA_MIN_ALIGNMENT_PAGES)
>
> struct cma;
> +struct folio;
> +
> +bool cma_folio_is_longterm_pinnable(struct folio *folio);
>
> extern unsigned long totalcma_pages;
> extern phys_addr_t cma_get_base(const struct cma *cma);
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 6af3b7008f1ad..5392e225cab9b 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3,6 +3,7 @@
> #define _LINUX_MM_H
>
> #include <linux/args.h>
> +#include <linux/cma.h>
> #include <linux/errno.h>
> #include <linux/mmdebug.h>
> #include <linux/gfp.h>
> @@ -2975,7 +2976,10 @@ 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 */
> +/*
> + * MIGRATE_CMA and ZONE_MOVABLE folios cannot normally be long-term pinned.
> + * CMA may allow pinning folios explicitly allocated from its areas.
> + */
> #ifdef CONFIG_MIGRATION
> static inline bool folio_is_longterm_pinnable(struct folio *folio)
> {
> @@ -2983,7 +2987,7 @@ static inline bool folio_is_longterm_pinnable(struct folio *folio)
> int mt = folio_migratetype(folio);
>
> if (mt == MIGRATE_CMA || mt == MIGRATE_ISOLATE)
> - return false;
> + return cma_folio_is_longterm_pinnable(folio);
> #endif
> /* The zero page can be "pinned" but gets special handling. */
> if (is_zero_folio(folio))
> diff --git a/mm/cma.c b/mm/cma.c
> index 9ec1d1fd5dff5..b3bf0014a90f5 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -27,6 +27,7 @@
> #include <linux/log2.h>
> #include <linux/cma.h>
> #include <linux/highmem.h>
> +#include <linux/hugetlb.h>
> #include <linux/io.h>
> #include <linux/kmemleak.h>
> #include <trace/events/cma.h>
> @@ -38,6 +39,16 @@
> struct cma cma_areas[MAX_CMA_AREAS];
> unsigned int cma_area_count;
>
> +bool cma_folio_is_longterm_pinnable(struct folio *folio)
> +{
> + /*
> + * Explicitly allocated CMA folios own their bitmap ranges and can be
> + * pinned even in ZONE_MOVABLE, as CMA memory cannot be offlined.
> + * For now, only HugeTLB tracks these allocations with a folio flag.
> + */
> + return folio_test_hugetlb(folio) && folio_test_hugetlb_cma(folio);
> +}
> +
> phys_addr_t cma_get_base(const struct cma *cma)
> {
> WARN_ON_ONCE(cma->nranges != 1);
next prev parent reply other threads:[~2026-11-12 9:04 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
2026-11-12 6:13 ` Qi Zheng
2026-11-12 8:49 ` David Hildenbrand (Arm)
2026-11-12 9:04 ` Qi Zheng [this message]
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=cc8c4c79-e7b4-46f7-b8a2-b5564b3cc85a@linux.dev \
--to=qi.zheng@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=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--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.