On 10/15/24 2:04 PM, Dave Hansen wrote: > 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. Doesn't ring a bell, and haven't had anyone report that before. The older io_uring code does indeed use remap_pfn_range(), this is gone in newer kernels. But in any case, I can't seem to trigger this on 5.15-stable, I might be missing something in my .config... -- Jens Axboe
