On 14.10.20 13:53, Michal Privoznik wrote: > On 10/14/20 10:26 AM, David Hildenbrand wrote: >> On 14.10.20 08:30, Michal Privoznik wrote: > > Sorry for hijacking this thread, but I need to report it somewhere (what > is the best place?) > > When I want to start a guest with this feature turned on + memfd + > hugepages, the host kernel prints this warning into dmesg and hugepages > stop working from then on (meaning, even if the pool of allocated HPs is > large enough I can't start any guest with HPs): > > > > > [ 139.434748] ------------[ cut here ]------------ > [ 139.434754] WARNING: CPU: 2 PID: 6280 at mm/page_counter.c:57 > page_counter_uncharge+0x33/0x40 > [ 139.434754] Modules linked in: kvm_amd amdgpu kvm btusb btrtl btbcm > btintel sp5100_tco watchdog k10temp mfd_core gpu_sched ttm > [ 139.434759] CPU: 2 PID: 6280 Comm: CPU 1/KVM Not tainted > 5.8.13-gentoo-x86_64 #2 > [ 139.434759] Hardware name: System manufacturer System Product > Name/PRIME X570-PRO, BIOS 1005 08/01/2019 > [ 139.434760] RIP: 0010:page_counter_uncharge+0x33/0x40 > [ 139.434762] Code: 48 85 ff 74 24 4c 89 c8 f0 48 0f c1 07 4c 29 c0 48 > 89 c1 48 89 c6 e8 7c fe ff ff 48 85 c9 78 0a 48 8b 7f 28 48 85 ff 75 dc > c3 <0f> 0b eb f2 66 0f 1f 84 00 00 00 00 00 48 8b 17 48 39 d6 72 41 41 > [ 139.434762] RSP: 0018:ffffc9000355fb38 EFLAGS: 00010286 > [ 139.434763] RAX: fffffffffffb4000 RBX: ffff888fc267e900 RCX: > fffffffffffb4000 > [ 139.434763] RDX: 0000000000000402 RSI: fffffffffffb4000 RDI: > ffff888fd8411dd0 > [ 139.434764] RBP: ffff888fcba983c0 R08: 0000000000080400 R09: > fffffffffff7fc00 > [ 139.434764] R10: ffffc9000355fb40 R11: 000000000000000a R12: > 0000000000000001 > [ 139.434765] R13: ffff888fc3d89140 R14: 00000000000001b2 R15: > 00000000000001b1 > [ 139.434765] FS: 00007fc9d4c35700(0000) GS:ffff888fde880000(0000) > knlGS:0000000000000000 > [ 139.434766] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 139.434766] CR2: 00007f09a4003000 CR3: 0000000fc06fe000 CR4: > 0000000000340ee0 > [ 139.434767] Call Trace: > [ 139.434769] hugetlb_cgroup_uncharge_file_region+0x46/0x70 > [ 139.434772] region_del+0x1a0/0x260 > [ 139.434773] hugetlb_unreserve_pages+0x32/0xa0 > [ 139.434775] remove_inode_hugepages+0x19d/0x3a0 > [ 139.434776] hugetlbfs_fallocate+0x3f2/0x4a0 > [ 139.434778] ? __seccomp_filter+0x75/0x6a0 > [ 139.434779] vfs_fallocate+0x124/0x260 > [ 139.434780] __x64_sys_fallocate+0x39/0x60 > [ 139.434783] do_syscall_64+0x38/0x60 > [ 139.434784] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 139.434785] RIP: 0033:0x7fc9e0994de7 > [ 139.434786] Code: 89 7c 24 08 48 89 4c 24 18 e8 45 fc f8 ff 41 89 c0 > 4c 8b 54 24 18 48 8b 54 24 10 b8 1d 01 00 00 8b 74 24 0c 8b 7c 24 08 0f > 05 <48> 3d 00 f0 ff ff 77 41 44 89 c7 89 44 24 08 e8 75 fc f8 ff 8b 44 > [ 139.434787] RSP: 002b:00007fc9d4c337a0 EFLAGS: 00000293 ORIG_RAX: > 000000000000011d > [ 139.434787] RAX: ffffffffffffffda RBX: 0000000036400000 RCX: > 00007fc9e0994de7 > [ 139.434788] RDX: 0000000036200000 RSI: 0000000000000003 RDI: > 000000000000001d > [ 139.434788] RBP: 00007fc9d4c33800 R08: 0000000000000000 R09: > 0000000000000000 > [ 139.434789] R10: 0000000000200000 R11: 0000000000000293 R12: > 00007fff9a75c3fe > [ 139.434789] R13: 00007fff9a75c3ff R14: 00007fc9d4c35700 R15: > 00007fc9d4c33dc0 > [ 139.434790] ---[ end trace fb9808303959fc01 ]--- > > > Is this known problem? No, not at all. Thanks for reporting! And the "bad" thing is, that QEMU doesn't do anything too fancy. All it does is "fallocate(FALLOC_FL_PUNCH_HOLE)" on hugetlbfs when trying to zap reported pages. The same mechanism is also used for postcopy live migration and virtio-mem with hugetlbfs. Which kernel are you running? 1. Is it an upstream kernel, lkml + -mm lists are the right place (please cc me, or I can try to reproduce and report it). 2. Is it a distro kernel? Then create a BUG there. I was just recently testing virtio-mem with hugetlbfs and it worked on decent upstream Fedora. But maybe I was not able to trigger it. > > Michal > -- Thanks, David / dhildenb
