[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez3c=KS68hnLu26mw2qwkaT8__4cvFw8vdzK=R3QHv7XeQ@mail.gmail.com>
Date: Fri, 25 Oct 2024 17:20:52 +0200
From: Jann Horn <jannh@...gle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: syzbot <syzbot+0ca979b86eaec7337a89@...kaller.appspotmail.com>,
Liam.Howlett@...cle.com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, linux-usb@...r.kernel.org,
syzkaller-bugs@...glegroups.com, vbabka@...e.cz,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [syzbot] [mm?] INFO: rcu detected stall in vms_complete_munmap_vmas
On Fri, Oct 25, 2024 at 1:37 PM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
> On Fri, Oct 25, 2024 at 04:23:30AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: c6d9e43954bf Merge 6.12-rc4 into usb-next
> > git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> > console output: https://syzkaller.appspot.com/x/log.txt?x=139f225f980000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=4a2bb21f91d75c65
> > dashboard link: https://syzkaller.appspot.com/bug?extid=0ca979b86eaec7337a89
> > compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=179f225f980000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/3bf4a453ec2f/disk-c6d9e439.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/e4a2db2a5d95/vmlinux-c6d9e439.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/8eb8e481b288/bzImage-c6d9e439.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+0ca979b86eaec7337a89@...kaller.appspotmail.com
> >
>
> Isn't this just the same thing as [0]?
>
> Again I think we're just happening to hit a stall in the unmap logic rather than
> this being an mm thing.
>
> We retried that one a few times and it didn't hit any mm code after the
> first time.
Random side comment: It would be nice if the kernel was able to report
hangs in two steps; somehow scan and mark the stack in a first pass,
then wait another minute or so, then scan the stack again to see which
functions we haven't returned out of within that minute, or something
along those lines...
Powered by blists - more mailing lists