On 9/3/23, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Sun, Sep 03, 2023 at 10:33:57AM +0200, Mateusz Guzik wrote: >> On Sun, Sep 03, 2023 at 03:25:28PM +1000, Dave Chinner wrote: >> > On Sat, Sep 02, 2023 at 09:11:34PM -0700, syzbot wrote: >> > > Hello, >> > > >> > > syzbot found the following issue on: >> > > >> > > HEAD commit: b97d64c72259 Merge tag >> > > '6.6-rc-smb3-client-fixes-part1' of.. >> > > git tree: upstream >> > > console output: >> > > https://syzkaller.appspot.com/x/log.txt?x=14136d8fa80000 >> > > kernel config: >> > > https://syzkaller.appspot.com/x/.config?x=958c1fdc38118172 >> > > dashboard link: >> > > https://syzkaller.appspot.com/bug?extid=e245f0516ee625aaa412 >> > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for >> > > Debian) 2.40 >> > > >> > > Unfortunately, I don't have any reproducer for this issue yet. >> > >> > Been happening for months, apparently, yet for some reason it now >> > thinks a locking hang in __fdget_pos() is an XFS issue? >> > >> > #syz set subsystems: fs >> > >> >> The report does not have info necessary to figure this out -- no >> backtrace for whichever thread which holds f_pos_lock. I clicked on a >> bunch of other reports and it is the same story. >> >> Can the kernel be configured to dump backtraces from *all* threads? >> >> If there is no feature like that I can hack it up. > > <break>t > > over serial console, or echo t >/proc/sysrq-trigger would do it... > This does not dump backtraces, just a list of tasks + some stats. The closest to useful here I found are 'w' ("Dumps tasks that are in uninterruptable (blocked) state.") and 'l' ("Shows a stack backtrace for all active CPUs."), both of which can miss the task which matters (e.g., stuck in a very much *interruptible* state with f_pos_lock held). Unless someone can point at a way to get all these stacks, I'm going to hack something up in the upcoming week, if only for immediate syzbot usage. -- Mateusz Guzik <mjguzik gmail.com>
