On Wed, Jan 06, 2021 at 11:03:09PM -0800, syzbot wrote: > syzbot suspects this issue was fixed by commit: > > commit dfefd226b0bf7c435a58d75a0ce2f9273b9825f6 > Author: Alexey Dobriyan <adobriyan@xxxxxxxxx> > Date: Tue Dec 15 03:15:03 2020 +0000 > > mm: cleanup kstrto*() usage This is a nonsense bisect result; I've filed a bug against syzbot[1]. [1] https://github.com/google/syzkaller/issues/3855 Looking more closely at this reproducer, it looks like it is setting up a and configuring userfaultd on a large number of threads: clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x11ad690) res = syscall(__NR_userfaultfd, 0ul); syscall(__NR_ioctl, r[0], UFFDIO_API, {api=0xaa, features=0, ... }); syscall(__NR_ioctl, -1, PPPIOCGMRU, 0ul) returns -EBADF (don't know why the syzbot minimizer didn't get rid of this...) syscall(__NR_ioctl, r[0], UFFDIO_REGISTER, {range={start=0x20909000, len=0x4000}, mode=UFFDIO_REGISTER_MODE_MISSING ...) ... It does this in a tight loop, spawning many threads each time, and while it doesen't always end up reporting an rcu preempt stall, and locking up the kernel, I have manage to trigger a similar crash when the underlying file system is btrfs, with the stack traces being similar. So I don't believe it is an ext4-specific bug. #syz set subsystems: fs I'm not an expert on userfaultd, but I'm not at all convinced what this reproducer is doing is valid and it may be a "root an screw itself" kind of issue. Maybe someone who knows more about userfaultfd can comment? There is a C reproducer[2], but it suffers from the standard obfuscation via ultra-non-portable-C-so-much-it-might-as- well-be-asm problem. The syzbot dashboard page for this can be found here[3]. [2] https://syzkaller.appspot.com/text?tag=ReproC&x=153a741e100000 [3] https://syzkaller.appspot.com/bug?id=d38f8eae55e27aaef60b4748bc77ecb712dba4b9 Thanks, - Ted
