On Tue, Sep 24, 2024 at 04:45:00PM +0200, David Hildenbrand wrote: > On 23.09.24 14:18, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 88264981f208 Merge tag 'sched_ext-for-6.12' of git://git.k.. > > git tree: upstream > > console+strace: https://syzkaller.appspot.com/x/log.txt?x=16c36c27980000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=e851828834875d6f > > dashboard link: https://syzkaller.appspot.com/bug?extid=bf2c35fa302ebe3c7471 > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12773080580000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16ed5e9f980000 > > > > Downloadable assets: > > disk image: https://storage.googleapis.com/syzbot-assets/0e011ac37c93/disk-88264981.raw.xz > > vmlinux: https://storage.googleapis.com/syzbot-assets/f5c65577e19e/vmlinux-88264981.xz > > kernel image: https://storage.googleapis.com/syzbot-assets/984d963c8ea1/bzImage-88264981.xz > > > > The issue was bisected to: > > > > commit 75182022a0439788415b2dd1db3086e07aa506f7 > > Author: Peter Xu <peterx@xxxxxxxxxx> > > Date: Mon Aug 26 20:43:51 2024 +0000 > > > > mm/x86: support large pfn mappings > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17df9c27980000 > > final oops: https://syzkaller.appspot.com/x/report.txt?x=143f9c27980000 > > console output: https://syzkaller.appspot.com/x/log.txt?x=103f9c27980000 > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+bf2c35fa302ebe3c7471@xxxxxxxxxxxxxxxxxxxxxxxxx > > Fixes: 75182022a043 ("mm/x86: support large pfn mappings") > > > > ------------[ cut here ]------------ > > WARNING: CPU: 1 PID: 5508 at mm/huge_memory.c:1602 copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602 > > This is the > > VM_WARN_ON_ONCE(is_cow_mapping(src_vma->vm_flags) && pmd_write(pmd)) > > So we have a special-marked PMD in a COW mapping. > > The reproducer seems to involve fuse, but not sure if that makes a > difference here. That chunk of code seems to be there only making sure the test won't get blocked due to any fused based fs being stuck, via writting to the "abort" file: snprintf(abort, sizeof(abort), "/sys/fs/fuse/connections/%s/abort", ent->d_name); int fd = open(abort, O_WRONLY); if (fd == -1) { continue; } if (write(fd, abort, 1) < 0) { } close(fd); So far looks not relevant to this issue indeed. Unfortunately I cannot reproduce it even with the reproducer. So this one is a bit tricky.. What confuses me yet is how that special bit is set, if it's only used so far with vfio-pci, and this test doesn't seem to have it involved. The test keeps invoking processes, then threads, doing concurrent accesses over a few stuff (madvise, mremap, migrate_pages, munmap, etc.) on the pre-mapped areas, but none of them seem to create new memory that can provide hint on how special bit can start to occur. I wonder if some of these operations can race in a way that mm can wrongly create the special bit (alone with it being writable).. and then it could be a historical bug, only captured by this patchset due to the newly added WARN_ON_ONCE somehow, then it could mean that it's not the WRITE bit that is not intended, but the SPECIAL bit altogether. Thanks, -- Peter Xu
