Preston_PLB
/
kernel-aes67
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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>
This commit is contained in:
Matthew Wilcox (Oracle) 2023-12-11 16:22:10 +00:00 committed by Andrew Morton
parent 2853b66b60
commit b2926ac817
1 changed files with 4 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
mm/memremap.c
View File

@ -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