| Message ID | 20231211162214.2146080-6-willy@infradead.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Finish two folio conversions | expand |
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>
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
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(-)