Messages in this thread | | | Date | Fri, 28 Jul 2023 19:54:54 +0200 | Subject | Re: [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone fallout | From | David Hildenbrand <> |
| |
[...]
> > There was the case for "FOLL_PIN represents application behavior and > should trigger NUMA faults", but I guess that can be ignored. > > But it would be much better to just remove all that if we can. > > Let me look into some details.
I just stumbled over the comment from Mel in follow_trans_huge_pmd():
/* Full NUMA hinting faults to serialise migration in fault paths */
It dates back to
commit 2b4847e73004c10ae6666c2e27b5c5430aed8698 Author: Mel Gorman <mgorman@suse.de> Date: Wed Dec 18 17:08:32 2013 -0800
mm: numa: serialise parallel get_user_page against THP migration Base pages are unmapped and flushed from cache and TLB during normal page migration and replaced with a migration entry that causes any parallel NUMA hinting fault or gup to block until migration completes. THP does not unmap pages due to a lack of support for migration entries at a PMD level. This allows races with get_user_pages and get_user_pages_fast which commit 3f926ab945b6 ("mm: Close races between THP migration and PMD numa clearing") made worse by introducing a pmd_clear_flush(). This patch forces get_user_page (fast and normal) on a pmd_numa page to go through the slow get_user_page path where it will serialise against THP migration and properly account for the NUMA hinting fault. On the migration side the page table lock is taken for each PTE update.
We nowadays do have migration entries at PMD level -- and setting FOLL_FORCE could similarly trigger such a race.
So I suspect we're good.
-- Cheers,
David / dhildenb
| |