[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9ebc4798-9889-4245-9cc6-f3192d00cfdc@lucifer.local>
Date: Fri, 25 Oct 2024 16:46:54 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jann Horn <jannh@...gle.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 05:20:52PM +0200, Jann Horn wrote:
> 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...
Yeah that'd be nice!
You'd get more information that way, though of course one stalled task might
hold a lock another actually in theory unstalled task might need thus
deadlocking it... :)
But at least you'd see that, and the lock splat there helps obviously.
Powered by blists - more mailing lists