Re: [RFC][PATCH v2 1/5] mm: Avoid unmapping pinned pages
From: Nadav Amit <hidden>
Date: 2022-01-20 18:03:53
Also in:
linux-mm, lkml
On Jan 20, 2022, at 7:55 AM, Peter Zijlstra [off-list ref] wrote: Add a guarantee for Anon pages that pin_user_page*() ensures the user-mapping of these pages stay preserved. In order to ensure this all rmap users have been audited: vmscan: already fails eviction due to page_maybe_dma_pinned() migrate: migration will fail on pinned pages due to expected_page_refs() not matching, however that is *after* try_to_migrate() has already destroyed the user mapping of these pages. Add an early exit for this case. numa-balance: as per the above, pinned pages cannot be migrated, however numa balancing scanning will happily PROT_NONE them to get usage information on these pages. Avoid this for pinned pages. None of the other rmap users (damon,page-idle,mlock,..) unmap the page, they mostly just muck about with reference,dirty flags etc. This same guarantee cannot be provided for Shared (file) pages due to dirty page tracking.
[ snip ]
quoted hunk ↗ jump to hunk
--- a/mm/mprotect.c +++ b/mm/mprotect.c@@ -106,6 +106,12 @@ static unsigned long change_pte_range(stcontinue; /* + * Can't migrate pinned pages, avoid touching them. + */ + if (page_maybe_dma_pinned(page)) + continue; + + /*
I have a similar problem with userfaultfd changing protection for DMA-pinned pages. For userfaultfd it is important to know how many pages were actually modified. I am working on a vectored UFFDIO_WRITEPROTECTV that aborts once a pinned page is encountered, but also returns the number of pages that were properly protected. I still need to do some work to send patches for that as it requires further changes (to return the number of pages that were handled). But for the matter of your patch, is it possible to make this test generic (not migration specific) and rely on a new flag in cp_flags? I can of course make this change later if you prefer it this way.