On 10/15/24 11:55, Marius Fleischer wrote: > Hope you are doing well! > > Quick update from our side: The reproducer from the previous email > still triggers a WARNING on v5.15 (commit hash > 3a5928702e7120f83f703fd566082bfb59f1a57e). Happy to also test on > other kernel versions if that helps. > > Please let us know if there is any other helpful information we can provide. I don't know for sure, but I suspect that io_uring is triggering this. The reproducer is: syz_io_uring_setup(0x6f7e, &(0x7f0000000080), 0x0, 0x0) syz_clone(0x24080, 0x0, 0x0, 0x0, 0x0, 0x0) (fail_nth: 40) and the stack trace shows: untrack_pfn+0xdc/0x240 arch/x86/mm/pat/memtype.c:1122 ... __mmput+0x122/0x4b0 kernel/fork.c:1126 ... __do_sys_clone+0xc8/0x110 kernel/fork.c:2721 So whatever is happening is going on with a VM_PFNMAP VMA. Those aren't super common except when you're mmap()'ing something from a device driver. I would randomly guess that io_uring_setup() is setting up a VM_PFNMAP VMA and untrack_pfn() is getting called when that VMA is getting torn down. The other goofiness is that the copy_mm() path is ending up in exit_mmap(). I think the only way to end up doing that is in the failure path of dup_mm(). So I *think* what happens is that a io_uring VMA gets created in dup_mmap(), but never gets any pages faulted in. Some later setup fails and the new mm needs to be torn down. *Something* about the io_uring VMA screws up the untrack_pfn() code. I'm hoping that this rings a bell with the io_uring folks and this is a bug they've found and fixed in mainline that just got missed backporting to stable.
