On 02.05.22 19:35, Minchan Kim wrote:
> Pages on CMA area could have MIGRATE_ISOLATE as well as MIGRATE_CMA
> so current is_pinnable_page could miss CMA pages which has MIGRATE_
> ISOLATE. It ends up putting CMA pages longterm pinning possible on
> pin_user_pages APIs so CMA allocation fails.
>
> The CMA allocation path protects the migration type change race
> using zone->lock but what GUP path need to know is just whether the
> page is on CMA area or not rather than exact type. Thus, we don't
> need zone->lock but just checks the migratype in either of
> (MIGRATE_ISOLATE and MIGRATE_CMA).
>
> Signed-off-by: Minchan Kim <minchan@xxxxxxxxxx>
> ---
> include/linux/mm.h | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 6acca5cecbc5..f59bbe3296e3 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1625,8 +1625,10 @@ static inline bool page_needs_cow_for_dma(struct vm_area_struct *vma,
> #ifdef CONFIG_MIGRATION
> static inline bool is_pinnable_page(struct page *page)
> {
> - return !(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||
> - is_zero_pfn(page_to_pfn(page));
> + int mt = get_pageblock_migratetype(page);
> +
> + return !(is_zone_movable_page(page) || mt == MIGRATE_CMA ||
> + mt == MIGRATE_ISOLATE || is_zero_pfn(page_to_pfn(page)));
> }
> #else
> static inline bool is_pinnable_page(struct page *page)
That implies that other memory ranges that are currently isolated
(memory offlining, alloc_contig_range()) cannot be pinned. That might
not be a bad thing, however, I think we could end up failing to pin
something that's temporarily unmovable (due to temporary references).
However, I assume we have the same issue right now already with
ZONE_MOVABLE and MIGRATE_CMA when trying to pin a page residing on these
there are temporarily unmovable and we fail to migrate. But it would now
apply even without ZONE_MOVABLE or MIGRATE_CMA. Hm...
--
Thanks,
David / dhildenb
