mm: remove stale example from comment

folio_add_new_anon_rmap() no longer works this way, so just remove the
entire example.

Link: https://lkml.kernel.org/r/20231211162214.2146080-6-willy@infradead.org
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/mm/memremap.c b/mm/memremap.c
index 9531faa92a7c4d04920ee80f2ab1fb8f6e66d1e3..9e9fb1972fff0af257d8b278012b44d7c7820bcd 100644 (file)
--- 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