Re: [PATCH 5/9] mm: Remove stale example from comment

[David Hildenbrand <david@redhat.com>]

On 11.12.23 17:22, Matthew Wilcox (Oracle) wrote:
> folio_add_new_anon_rmap() no longer works this way, so just remove the
> entire example.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> Cc: Ralph Campbell <rcampbell@nvidia.com>
> ---
>   mm/memremap.c | 18 ++++--------------
>   1 file changed, 4 insertions(+), 14 deletions(-)
> 
> diff --git a/mm/memremap.c b/mm/memremap.c
> index 9531faa92a7c..9e9fb1972fff 100644
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -473,21 +473,11 @@ void free_zone_device_page(struct page *page)
>   		__ClearPageAnonExclusive(page);
>   
>   	/*
> -	 * When a device managed page is freed, the page->mapping field
> +	 * When a device managed page is freed, the folio->mapping field
>   	 * may still contain a (stale) mapping value. For example, the
> -	 * lower bits of page->mapping may still identify the page as an
> -	 * anonymous page. Ultimately, this entire field is just stale
> -	 * and wrong, and it will cause errors if not cleared.  One
> -	 * example is:
> -	 *
> -	 *  migrate_vma_pages()
> -	 *    migrate_vma_insert_page()
> -	 *      page_add_new_anon_rmap()
> -	 *        __page_set_anon_rmap()
> -	 *          ...checks page->mapping, via PageAnon(page) call,
> -	 *            and incorrectly concludes that the page is an
> -	 *            anonymous page. Therefore, it incorrectly,
> -	 *            silently fails to set up the new anon rmap.
> +	 * lower bits of folio->mapping may still identify the folio as an
> +	 * anonymous folio. Ultimately, this entire field is just stale
> +	 * and wrong, and it will cause errors if not cleared.
>   	 *
>   	 * For other types of ZONE_DEVICE pages, migration is either
>   	 * handled differently or not done at all, so there is no need

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 
Cheers,

David / dhildenb