On Mon, 2021-02-01 at 14:37 +0200, Mike Rapoport wrote: > On Mon, Feb 01, 2021 at 01:17:13AM -0800, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: b01f250d Add linux-next specific files for 20210129 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=14daa408d00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=725bc96dc234fda7 > > dashboard link: https://syzkaller.appspot.com/bug?extid=2ae0ca9d7737ad1a62b7 > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1757f2a0d00000 > > > > The issue was bisected to: > > > > commit cc9327f3b085ba5be5639a5ec3ce5b08a0f14a7c > > Author: Mike Rapoport <rppt@xxxxxxxxxxxxx> > > Date: Thu Jan 28 07:42:40 2021 +0000 > > > > mm: introduce memfd_secret system call to create "secret" memory areas > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1505d28cd00000 > > final oops: https://syzkaller.appspot.com/x/report.txt?x=1705d28cd00000 > > console output: https://syzkaller.appspot.com/x/log.txt?x=1305d28cd00000 > > Sounds really weird to me. At this point the memfd_secret syscall is not > even wired to arch syscall handlers. I cannot see how it can be a reason of > deadlock in wireless... Yeah, forget about it. Usually this is a consequence of the way syzbot creates tests - it might have created something like if (!create_secret_memfd()) return; try_something_on_wireless() and then of course without your patch it cannot get to the wireless bits. Pretty sure I know what's going on here, I'll take a closer look later. johannes
