On Thu, Jan 12, 2023 at 9:56 AM Kirill A. Shutemov wrote: > On Wed, Jan 11, 2023 at 02:33:51PM +0100, Jann Horn wrote: > > If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires > > it to be locked. retract_page_tables() bails out if an ->anon_vma is > > attached, but does this check before holding the mmap lock (as the comment > > above the check explains). > > > > If we racily merge an existing ->anon_vma (shared with a child process) > > from a neighboring VMA, subsequent rmap traversals on pages belonging to > > the child will be able to see the page tables that we are concurrently > > removing while assuming that nothing else can access them. > > > > Repeat the ->anon_vma check once we hold the mmap lock to ensure that there > > really is no concurrent page table access. > > > > Reported-by: Zach O'Keefe > > Fixes: f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages") > > Cc: stable@vger.kernel.org > > Signed-off-by: Jann Horn > > --- > > zokeefe@ pointed out to me that the current code (after my last round of patches) > > can hit a lockdep assert by racing, and after staring at it a bit I've > > convinced myself that this is a real, preexisting bug. > > (I haven't written a reproducer for it though. One way to hit it might be > > something along the lines of: > > > > - set up a process A with a private-file-mapping VMA V1 > > - let A fork() to create process B, thereby copying V1 in A to V1' in B > > - let B extend the end of V1' > > - let B put some anon pages into the extended part of V1' > > At this point V1' gets it's own ->anon_vma, not connected to V1, right? Yes, true, it doesn't work in a child process because reusable_anon_vma() refuses to reuse the anon_vma of an adjacent VMA if that VMA is attached to more than one VMA. So to actually make it work, you have to rearrange things a bit such that this happens in the parent process, so that prepare_anon_vma() will reuse a neighboring anon_vma via reusable_anon_vma(). Sorry, my description of the race was slightly off. See the attached code for how to actually do it. Basically the trick is to use mremap() to take one private file VMA with an anon_vma and turn it into two private file VMAs ("mapping1" and "mapping2" in my code) with the same anon_vma that map the same file range. Put an anonymous page into mapping1. Then you can replace the first 2 MiB of "mapping2" with another VMA that is not mergeable into mapping2, is anon_vma-compatible with mapping2, has no anon_vma, and looks THP-collapsible. And then you can, while khugepaged is in the race window, attach the new VMA to the existing anon_vma and trigger an rmap walk on the anonymous page. > > - let A map a new private-file-mapping VMA V2 directly behind V1, without > > an anon_vma > > [race begins here] > > - in A's thread 1: begin retract_page_tables() on V2, run through first > > ->anon_vma check > > - in A's thread 2: run __anon_vma_prepare() on V2 and ensure that it > > merges the anon_vma of V1 (which implies V1 and V2 must be mapping the > > same file at compatible offsets) > > - in B: trigger rmap traversal on anon page in V1' > > I don't follow the race. rmap on V1' will not reach V1. > > > mm/khugepaged.c | 14 +++++++++++++- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > > index 5cb401aa2b9d..0bfed37f3a3b 100644 > > --- a/mm/khugepaged.c > > +++ b/mm/khugepaged.c > > @@ -1644,7 +1644,7 @@ static int retract_page_tables(struct address_space *mapping, pgoff_t pgoff, > > * has higher cost too. It would also probably require locking > > * the anon_vma. > > */ > > - if (vma->anon_vma) { > > + if (READ_ONCE(vma->anon_vma)) { > > result = SCAN_PAGE_ANON; > > goto next; > > } > > This makes perfect sense. At least for readability. But I think > false-negative should not lead to bad results. > > > @@ -1672,6 +1672,18 @@ static int retract_page_tables(struct address_space *mapping, pgoff_t pgoff, > > result = SCAN_PTE_MAPPED_HUGEPAGE; > > if ((cc->is_khugepaged || is_target) && > > mmap_write_trylock(mm)) { > > + /* > > + * Re-check whether we have an ->anon_vma, because > > + * collapse_and_free_pmd() requires that either no > > + * ->anon_vma exists or the anon_vma is locked. > > + * We already checked ->anon_vma above, but that check > > + * is racy because ->anon_vma can be populated under the > > + * mmap lock in read mode. > > + */ > > + if (vma->anon_vma) { > > + result = SCAN_PAGE_ANON; > > + goto unlock_next; > > + } > > This is totally wrong direction. Or I don't understand the race. > > At this point we already paid nearly all price of of pagetable retraction. > I don't see any correctness reason to stop here, except for the assert. This condition can only be hit with a narrow race, since vma->anon_vma was NULL a moment ago. So this branch will only run very rarely, which means it is unlikely to have an effect on performance. > I think lockdep assert in collapse_and_free_pmd() is wrong and has to be > dropped. No, that lockdep assert has to be there. Page table traversal is allowed under any one of the mmap lock, the anon_vma lock (if the VMA is associated with an anon_vma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove page tables, we must hold all three of them. Even if we couldn't figure out a way to actually exploit a lack of locking here, we still shouldn't be skipping locking because of that. Unless we have clearly defined API contracts such as "you are allowed to traverse page tables if you hold one of these three locks", it is impossible to maintain code or to make it robust and secure. Even if you could show that the lack of locking can't lead to a crash in the current kernel, that still wouldn't be a good reason to skip the locking. Without something at least resembling an API contract, an innocent-looking change in another part of the kernel can turn things in a completely different part of the kernel into dangerous bugs, and it is impossible to change anything while feeling confident that you haven't broken something halfway across the kernel. (Or at least that's what it feels like to me when I try to edit kernel code.) Anyway, here are proper instructions for reproducing the bug. First build the kernel with the attached patch HACK-thp-anonvma-logging-and-delay.diff, which adds a bunch of debug logging and injects extra timing delays to make the race much easier to hit. Then build with CONFIG_KASAN=y and CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y and lockdep, and run that kernel. Run "echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled" to enable shmem THP. Compile the attached reproducer thp_newbug.c ("gcc -o thp_newbug thp_newbug.c"). Let the reproducer run (it'll take a few seconds to run because it has to wait for khugepaged and stuff). Then you should see a lockdep assert failure followed by an ASAN splat due to page table UAF in dmesg: [ 1076.064348][ T116] khugepaged: retract_page_tables: retract_page_tables(), cc->is_khugepaged=1, target_mm=ffff88817b4acc80 [ 1076.066331][ T116] khugepaged: retract_page_tables: running on vma at 0x1fe000 in mm=ffff88817b4acc80 [ 1076.068464][ T116] khugepaged: retract_page_tables: about to call collapse_and_free_pmd() [ 1076.071078][ T116] khugepaged: retract_page_tables: done with collapse_and_free_pmd() [ 1076.072360][ T116] khugepaged: retract_page_tables: sleeping before mmap lock... [ 1076.135883][ T797] map_pte: executing under TEST1 pvmw->vma->vm_mm==ffff88817b4acc80 pvmw->vma->vm_start=0x23ff000 [ 1076.147212][ T797] map_pte: ... begin delay... [ 1079.074924][ T116] khugepaged: retract_page_tables: done sleeping [ 1079.075874][ T116] khugepaged: retract_page_tables: about to call collapse_and_free_pmd() [ 1079.076964][ T116] ------------[ cut here ]------------ [ 1079.077663][ T116] WARNING: CPU: 14 PID: 116 at mm/khugepaged.c:1406 collapse_and_free_pmd+0x364/0x420 [ 1079.078940][ T116] CPU: 14 PID: 116 Comm: khugepaged Not tainted 6.2.0-rc3-00060-gc757fc92a3f7-dirty #257 [ 1079.080191][ T116] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014 [ 1079.081462][ T116] RIP: 0010:collapse_and_free_pmd+0x364/0x420 [ 1079.082290][ T116] Code: ae 7e e6 03 85 d2 0f 84 b3 fd ff ff 4c 89 ff e8 52 86 fe ff 49 8b 3f 31 f6 48 83 c7 78 e8 34 56 e3 01 85 c0 0f 85 95 fd ff ff <0f> 0b e9 8e fd ff ff e8 d0 13 e8 ff ba ff ff ff ff be 26 00 00 00 [ 1079.084735][ T116] RSP: 0018:ffffc900009b79b0 EFLAGS: 00010246 [ 1079.085527][ T116] RAX: 0000000000000000 RBX: ffff88817b4acc80 RCX: 0000000000000001 [ 1079.089956][ T116] RDX: 0000000000000000 RSI: ffffffffa5cab020 RDI: ffffffffa5e382e0 [ 1079.090967][ T116] RBP: 1ffff92000136f36 R08: 0000000000000000 R09: ffff88817b4acd6f [ 1079.091942][ T116] R10: ffffed102f6959ad R11: 0000000000000001 R12: ffff888117b0a3e8 [ 1079.092953][ T116] R13: 0000000002400000 R14: ffff888171ad1090 R15: ffff8881149b1100 [ 1079.094066][ T116] FS: 0000000000000000(0000) GS:ffff8881f7100000(0000) knlGS:0000000000000000 [ 1079.095387][ T116] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1079.096379][ T116] CR2: 000055c6faaf9578 CR3: 0000000111738005 CR4: 0000000000370ee0 [ 1079.097695][ T116] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1079.098909][ T116] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1079.100117][ T116] Call Trace: [ 1079.100668][ T116] [...] [ 1079.106003][ T116] collapse_file.cold+0x3a4/0x400 [...] [ 1079.110117][ T116] hpage_collapse_scan_file+0x72a/0xad0 [ 1079.110856][ T116] ? lock_release+0x22e/0x460 [ 1079.111483][ T116] ? __pfx_hpage_collapse_scan_file+0x10/0x10 [ 1079.112289][ T116] khugepaged+0x66b/0xbf0 [...] [ 1079.118911][ T116] kthread+0x17e/0x1b0 [ 1079.119440][ T116] ? __pfx_kthread+0x10/0x10 [ 1079.120012][ T116] ret_from_fork+0x2c/0x50 [ 1079.120593][ T116] [ 1079.120971][ T116] irq event stamp: 12259 [ 1079.121520][ T116] hardirqs last enabled at (12271): [] __up_console_sem+0x5e/0x70 [ 1079.122735][ T116] hardirqs last disabled at (12282): [] __up_console_sem+0x43/0x70 [ 1079.123950][ T116] softirqs last enabled at (12018): [] __irq_exit_rcu+0xd8/0x140 [ 1079.125151][ T116] softirqs last disabled at (12013): [] __irq_exit_rcu+0xd8/0x140 [ 1079.126342][ T116] ---[ end trace 0000000000000000 ]--- [ 1079.140447][ T116] khugepaged: retract_page_tables: done with collapse_and_free_pmd() [ 1079.143002][ T116] khugepaged: retract_page_tables: skipping vma at 0x1400000 in mm=ffff88817b4acc80 because anon_vma [ 1079.146490][ T116] khugepaged: retract_page_tables: skipping vma at 0x1400000 in mm=ffff88817b4a9980 because anon_vma [ 1079.159601][ T116] khugepaged: retract_page_tables: retract_page_tables(), cc->is_khugepaged=1, target_mm=ffff88817b4acc80 [ 1079.161186][ T116] khugepaged: retract_page_tables: skipping vma at 0x1400000 in mm=ffff88817b4acc80 because anon_vma [ 1079.162648][ T116] khugepaged: retract_page_tables: skipping vma at 0x1400000 in mm=ffff88817b4a9980 because anon_vma [ 1079.164000][ T116] khugepaged: retract_page_tables: skipping vma at 0x2600000 in mm=ffff88817b4acc80 because anon_vma [ 1079.649601][ T797] map_pte: ... end delay [ 1079.650358][ T797] ================================================================== [ 1079.651257][ T797] BUG: KASAN: use-after-free in page_vma_mapped_walk+0x5f3/0xdf0 [ 1079.652120][ T797] Read of size 8 at addr ffff888171e54000 by task TEST1/797 [ 1079.652915][ T797] [ 1079.653179][ T797] CPU: 13 PID: 797 Comm: TEST1 Tainted: G W 6.2.0-rc3-00060-gc757fc92a3f7-dirty #257 [ 1079.654410][ T797] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014 [ 1079.655534][ T797] Call Trace: [ 1079.655907][ T797] [ 1079.656268][ T797] dump_stack_lvl+0x5b/0x77 [ 1079.656812][ T797] print_report+0x168/0x458 [...] [ 1079.659003][ T797] kasan_report+0xbb/0xf0 [...] [ 1079.662829][ T797] page_vma_mapped_walk+0x5f3/0xdf0 [ 1079.663474][ T797] folio_referenced_one+0x1b3/0x3e0 [...] [ 1079.667670][ T797] rmap_walk_anon+0x137/0x2b0 [ 1079.668252][ T797] folio_referenced+0x298/0x2c0 [...] [ 1079.673519][ T797] shrink_folio_list+0xd30/0x1660 [...] [ 1079.679030][ T797] reclaim_folio_list.constprop.0+0xcf/0x200 [...] [ 1079.681772][ T797] reclaim_pages+0x154/0x1c0 [...] [ 1079.683727][ T797] madvise_cold_or_pageout_pte_range+0xf64/0x1900 [...] [ 1079.686125][ T797] walk_pgd_range+0x68a/0xcb0 [...] [ 1079.687393][ T797] __walk_page_range+0x25d/0x260 [...] [ 1079.689327][ T797] walk_page_range+0x253/0x2b0 [...] [ 1079.691922][ T797] madvise_pageout+0x1ab/0x2a0 [...] [ 1079.694355][ T797] do_madvise.part.0+0x3a3/0x1370 [...] [ 1079.701143][ T797] __x64_sys_madvise+0x7b/0xa0 [ 1079.701719][ T797] do_syscall_64+0x3a/0x90 [ 1079.702207][ T797] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 1079.702863][ T797] RIP: 0033:0x7f18ae2dfd07 [ 1079.703352][ T797] Code: ff ff ff ff c3 48 8b 15 87 61 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 66 2e 0f 1f 84 00 00 00 00 00 90 b8 1c 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 59 61 0c 00 f7 d8 64 89 01 48 [ 1079.705469][ T797] RSP: 002b:00007fffaaf31198 EFLAGS: 00000206 ORIG_RAX: 000000000000001c [ 1079.706382][ T797] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f18ae2dfd07 [ 1079.707244][ T797] RDX: 0000000000000015 RSI: 0000000000001000 RDI: 0000000001400000 [ 1079.710207][ T797] RBP: 00007fffaaf322c0 R08: 00007f18ae3a8800 R09: 00007f18ae3ad540 [ 1079.711092][ T797] R10: 00007f18ae2d6274 R11: 0000000000000206 R12: 00005577fac45220 [ 1079.712021][ T797] R13: 00007fffaaf323a0 R14: 0000000000000000 R15: 0000000000000000 [ 1079.712883][ T797] [ 1079.713219][ T797] [ 1079.713495][ T797] The buggy address belongs to the physical page: [ 1079.714273][ T797] page:000000009614ae4b refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171e54 [ 1079.715595][ T797] flags: 0x8000000000000000(zone=2) [ 1079.716275][ T797] raw: 8000000000000000 ffffea0004562e48 ffff8881f713d810 0000000000000000 [ 1079.717389][ T797] raw: 0000000000000000 ffff8881183f50c0 00000000ffffffff 0000000000000000 [ 1079.718508][ T797] page dumped because: kasan: bad access detected [ 1079.719358][ T797] page_owner tracks the page as freed [ 1079.720053][ T797] page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 796, tgid 796 (thp_newbug), ts 1065542415232, free_ts 1079140429026 [ 1079.722276][ T797] get_page_from_freelist+0xb0a/0x1300 [ 1079.722872][ T797] __alloc_pages+0x17e/0x3c0 [ 1079.723376][ T797] pte_alloc_one+0x18/0xe0 [ 1079.723885][ T797] __handle_mm_fault+0x15fa/0x1660 [ 1079.724474][ T797] handle_mm_fault+0x18c/0x4e0 [ 1079.724995][ T797] do_user_addr_fault+0x232/0x7f0 [ 1079.725551][ T797] exc_page_fault+0x5d/0xe0 [ 1079.726045][ T797] asm_exc_page_fault+0x22/0x30 [ 1079.726577][ T797] page last free stack trace: [ 1079.727089][ T797] free_pcp_prepare+0x276/0x530 [ 1079.727680][ T797] free_unref_page+0x37/0x250 [ 1079.728193][ T797] collapse_and_free_pmd+0x2a3/0x420 [ 1079.728773][ T797] collapse_file.cold+0x3a4/0x400 [ 1079.729321][ T797] hpage_collapse_scan_file+0x72a/0xad0 [ 1079.729939][ T797] khugepaged+0x66b/0xbf0 [ 1079.730426][ T797] kthread+0x17e/0x1b0 [ 1079.730874][ T797] ret_from_fork+0x2c/0x50 [ 1079.731393][ T797] [ 1079.731674][ T797] Memory state around the buggy address: [ 1079.732284][ T797] ffff888171e53f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1079.733154][ T797] ffff888171e53f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1079.734032][ T797] >ffff888171e54000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1079.734932][ T797] ^ [ 1079.735380][ T797] ffff888171e54080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1079.736249][ T797] ffff888171e54100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1079.737119][ T797] ================================================================== [ 1079.738129][ T797] Disabling lock debugging due to kernel taint [ 1079.738897][ T797] map_pte: executing under TEST1 pvmw->vma->vm_mm==ffff88817b4acc80 pvmw->vma->vm_start=0x1400000 [ 1079.744091][ T797] map_pte: ... continuing [ 1079.744621][ T797] map_pte: executing under TEST1 pvmw->vma->vm_mm==ffff88817b4a9980 pvmw->vma->vm_start=0x1400000 [ 1079.745802][ T797] map_pte: ... continuing Here's the corresponding reproducer output (including dumps of the anon_vma hierarchies attached to the VMAs, thanks to the extra debug info I added to procfs in the attached diff): user@vm:~/thp/thp_newbug$ ./thp_newbug Rss = 2048 kB [...] Rss = 2048 kB Rss = 2048 kB Rss = 2048 kB Rss = 2048 kB Rss = 0 kB khugepaged is about to write_trylock! associating anon_vma... anon_vma associated, telling child to hit rmap now... child hitting rmap... child done with rmap =========== PARENT =========== 001fe000-00400000 r--p 003fe000 00:01 13313 /memfd:memfd (deleted) Size: 2056 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 0 kB Pss: 0 kB Pss_Dirty: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Anonymous: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB FilePmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB THPeligible: 1 VmFlags: rd mr mw me dc hg 01400000-01800000 rw-p 00400000 00:01 13313 /memfd:memfd (deleted) Size: 4096 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 0 kB Pss: 0 kB Pss_Dirty: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Anonymous: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB FilePmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB THPeligible: 1 VmFlags: rd wr mr mw me ac AnonVMAs: # [ 0] ffff8881149b1100 root=ffff8881149b1100 refcount=2 anon_vmas=4 num_children=2 num_active_vmas=3 parent=ffff8881149b1100 023ff000-02600000 rwxp 003ff000 00:01 13313 /memfd:memfd (deleted) Size: 2052 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 4 kB Pss: 4 kB Pss_Dirty: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4 kB Referenced: 4 kB Anonymous: 4 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB FilePmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB THPeligible: 1 VmFlags: rd wr ex mr mw me dc ac AnonVMAs: # [ 0] ffff8881149b1100 root=ffff8881149b1100 refcount=2 anon_vmas=4 num_children=2 num_active_vmas=3 parent=ffff8881149b1100 02600000-02800000 rw-p 00600000 00:01 13313 /memfd:memfd (deleted) Size: 2048 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 0 kB Pss: 0 kB Pss_Dirty: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Anonymous: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB FilePmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB THPeligible: 1 VmFlags: rd wr mr mw me dc ac AnonVMAs: # [ 0] ffff8881149b1100 root=ffff8881149b1100 refcount=2 anon_vmas=4 num_children=2 num_active_vmas=3 parent=ffff8881149b1100 [...] =========== CHILD =========== 01400000-01800000 rw-p 00400000 00:01 13313 /memfd:memfd (deleted) Size: 4096 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 4 kB Pss: 4 kB Pss_Dirty: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4 kB Referenced: 0 kB Anonymous: 4 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB FilePmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB THPeligible: 1 VmFlags: rd wr mr mw me ac AnonVMAs: [ 0] ffff8881149b1100 root=ffff8881149b1100 refcount=2 anon_vmas=4 num_children=2 num_active_vmas=3 parent=ffff8881149b1100 # [ 1] ffff8881149b0cc0 root=ffff8881149b1100 refcount=1 anon_vmas=1 num_children=0 num_active_vmas=1 parent=ffff8881149b1100 [...] user@vm:~/thp/thp_newbug$