On Mon, 10 Feb 2025 20:37:42 +0100 David Hildenbrand <david@xxxxxxxxxx> wrote: > Against mm-hotfixes-stable for now. > > Discussing the PageTail() call in make_device_exclusive_range() with > Willy, I recently discovered [1] that device-exclusive handling does > not properly work with THP, making the hmm-tests selftests fail if THPs > are enabled on the system. > > Looking into more details, I found that hugetlb is not properly fenced, > and I realized that something that was bugging me for longer -- how > device-exclusive entries interact with mapcounts -- completely breaks > migration/swapout/split/hwpoison handling of these folios while they have > device-exclusive PTEs. > > The program below can be used to allocate 1 GiB worth of pages and > making them device-exclusive on a kernel with CONFIG_TEST_HMM. > > Once they are device-exclusive, these folios cannot get swapped out > (proc$pid/smaps_rollup will always indicate 1 GiB RSS no matter how > much one forces memory reclaim), and when having a memory block onlined > to ZONE_MOVABLE, trying to offline it will loop forever and complain about > failed migration of a page that should be movable. > > # echo offline > /sys/devices/system/memory/memory136/state > # echo online_movable > /sys/devices/system/memory/memory136/state > # ./hmm-swap & > ... wait until everything is device-exclusive > # echo offline > /sys/devices/system/memory/memory136/state > [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 > index:0x7f20671f7 pfn:0x442b6a > [ 285.196618][T14882] memcg:ffff888179298000 > [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| > dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) > [ 285.201734][T14882] raw: ... > [ 285.204464][T14882] raw: ... > [ 285.207196][T14882] page dumped because: migration failure > [ 285.209072][T14882] page_owner tracks the page as allocated > [ 285.210915][T14882] page last allocated via order 0, migratetype > Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), > id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774 > [ 285.216765][T14882] post_alloc_hook+0x197/0x1b0 > [ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280 > [ 285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740 > [ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540 > [ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340 > [ 285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0 > [ 285.229074][T14882] __handle_mm_fault+0x2b38/0x56a0 > [ 285.230822][T14882] handle_mm_fault+0x368/0x9f0 > ... > > This series fixes all issues I found so far. Cool. Barry, could you please redo your series "mm: batched unmap lazyfree large folios during reclamation" on top of this (on top of mm-unstable, ideally).
