All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	John Hubbard <jhubbard@nvidia.com>,
	John Dias <joaodias@google.com>, Jason Gunthorpe <jgg@ziepe.ca>,
	David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH v6] mm: fix is_pinnable_page against a cma page
Date: Tue, 24 May 2022 10:33:59 -0700	[thread overview]
Message-ID: <20220524173359.GR1790663@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <20220524171525.976723-1-minchan@kernel.org>

On Tue, May 24, 2022 at 10:15:25AM -0700, 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 pinning CMA pages as longterm at pin_user_pages
> APIs so CMA allocation keep failed until the pin is released.
> 
>      CPU 0                                   CPU 1 - Task B
> 
> cma_alloc
> alloc_contig_range
>                                         pin_user_pages_fast(FOLL_LONGTERM)
> change pageblock as MIGRATE_ISOLATE
>                                         internal_get_user_pages_fast
>                                         lockless_pages_from_mm
>                                         gup_pte_range
>                                         try_grab_folio
>                                         is_pinnable_page
>                                           return true;
>                                         So, pinned the page successfully.
> page migration failure with pinned page
>                                         ..
>                                         .. After 30 sec
>                                         unpin_user_page(page)
> 
> CMA allocation succeeded after 30 sec.
> 
> 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 migration type.
> Thus, we don't need zone->lock but just checks migration type in
> either of (MIGRATE_ISOLATE and MIGRATE_CMA).
> 
> Adding the MIGRATE_ISOLATE check in is_pinnable_page could cause
> rejecting of pinning pages on MIGRATE_ISOLATE pageblocks even
> though it's neither CMA nor movable zone if the page is temporarily
> unmovable. However, such a migration failure by unexpected temporal
> refcount holding is general issue, not only come from MIGRATE_ISOLATE
> and the MIGRATE_ISOLATE is also transient state like other temporal
> elevated refcount problem.
> 
> Cc: "Paul E . McKenney" <paulmck@kernel.org>

From a memory-ordering viewpoint:

Acked-by: Paul E. McKenney <paulmck@kernel.org>

> Cc: David Hildenbrand <david@redhat.com>
> Reviewed-by: John Hubbard <jhubbard@nvidia.com>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> ---
> * from v5 - https://lore.kernel.org/all/20220512204143.3961150-1-minchan@kernel.org/
>   * Use READ_ONCE in __get_pfnblock_flags_mask - Jason
>   * adding a comment about READ_ONCE - John
> 
> * from v4 - https://lore.kernel.org/all/20220510211743.95831-1-minchan@kernel.org/
>   * clarification why we need READ_ONCE - Paul
>   * Adding a comment about READ_ONCE - John
> 
> * from v3 - https://lore.kernel.org/all/20220509153430.4125710-1-minchan@kernel.org/
>   * Fix typo and adding more description - akpm
> 
> * from v2 - https://lore.kernel.org/all/20220505064429.2818496-1-minchan@kernel.org/
>   * Use __READ_ONCE instead of volatile - akpm
> 
> * from v1 - https://lore.kernel.org/all/20220502173558.2510641-1-minchan@kernel.org/
>   * fix build warning - lkp
>   * fix refetching issue of migration type
>   * add side effect on !ZONE_MOVABLE and !MIGRATE_CMA in description - david
> 
>  include/linux/mm.h | 9 +++++++--
>  mm/page_alloc.c    | 8 ++++++--
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 6acca5cecbc5..ba13411b6dca 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1625,8 +1625,13 @@ 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));
> +#ifdef CONFIG_CMA
> +	int mt = get_pageblock_migratetype(page);
> +
> +	if (mt == MIGRATE_CMA || mt == MIGRATE_ISOLATE)
> +		return false;
> +#endif
> +	return !(is_zone_movable_page(page) || is_zero_pfn(page_to_pfn(page)));
>  }
>  #else
>  static inline bool is_pinnable_page(struct page *page)
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7a2053621e27..348071e5d8d9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -482,8 +482,12 @@ unsigned long __get_pfnblock_flags_mask(const struct page *page,
>  	bitidx = pfn_to_bitidx(page, pfn);
>  	word_bitidx = bitidx / BITS_PER_LONG;
>  	bitidx &= (BITS_PER_LONG-1);
> -
> -	word = bitmap[word_bitidx];
> +	/*
> +	 * This races, without locks, with set_pfnblock_flags_mask(). Ensure
> +	 * a consistent read of the memory array, so that results, even though
> +	 * racy, are not corrupted.
> +	 */
> +	word = READ_ONCE(bitmap[word_bitidx]);
>  	return (word >> bitidx) & mask;
>  }
>  
> -- 
> 2.36.1.124.g0e6072fb45-goog
> 

      reply	other threads:[~2022-05-24 17:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24 17:15 [PATCH v6] mm: fix is_pinnable_page against a cma page Minchan Kim
2022-05-24 17:33 ` Paul E. McKenney [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=20220524173359.GR1790663@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=joaodias@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    /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.