linux-kernel - Re: [syzbot] [xfs?] INFO: task hung in __fdget

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANp29Y7CVJveEgQQj8qq2eyvtkdYqvuJuqePVAR7oky14N2i2g@mail.gmail.com>
Date:   Wed, 6 Sep 2023 19:53:22 +0200
From:   Aleksandr Nogikh <nogikh@...gle.com>
To:     Mateusz Guzik <mjguzik@...il.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Dave Chinner <david@...morbit.com>,
        syzbot <syzbot+e245f0516ee625aaa412@...kaller.appspotmail.com>,
        brauner@...nel.org, djwong@...nel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-xfs@...r.kernel.org, llvm@...ts.linux.dev, nathan@...nel.org,
        ndesaulniers@...gle.com, syzkaller-bugs@...glegroups.com,
        trix@...hat.com
Subject: Re: [syzbot] [xfs?] INFO: task hung in __fdget_pos (4)

On Sun, Sep 3, 2023 at 10:04 PM Mateusz Guzik <mjguzik@...il.com> wrote:
>
> On 9/3/23, Al Viro <viro@...iv.linux.org.uk> wrote:
> > On Sun, Sep 03, 2023 at 08:57:23PM +0200, Mateusz Guzik wrote:
> >
> >> 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.
> >
> > Huh?  Sample of output here:
> > 2023-09-03T15:34:36.271833-04:00 duke kernel: [87367.574459] task:ssh-agent
> >      state:S stack:0     pid:3949  ppid:3947   flags:0x
< .. >
> > 2023-09-03T15:34:36.457355-04:00 duke kernel: [87367.759981]  </TASK>
> >
> > Looks like a stack trace to me; seeing one of the callers of fdget_pos()
> > in that would tell you who's currently holding *some* ->f_pos_lock.
> >
> > That - on 6.1.42, with fairly bland .config (minimal debugging;
> > I need that box for fast builds, among other things).  Enable
> > lockdep and you'll get who's holding which logs in addition
> > to those stack traces...
> >
>
> That's my bad, the only content which survived for me in terminal
> buffer was a spew for the scheduler and a ps-like task list.
> Stacktraces are indeed there. Sorry for the noise on this one. I
> verified stack dumps are not gated by any defines either btw, so it's
> all good on this front.
>
> All this brainos aside, I added Aleksandr Nogikh to To: in my previous
> e-mail. From short poking around I found he was responsive to some
> queries concerning Linux vs syzbot and I figured would a good person
> to ask.
>
> So, Aleksandr, tl;dr would it be a problem to add the 't' sysrq to
> syzbot in order to dump backtraces from all threads? Either break t
> over a serial port or t written to /proc/sysrq-trigger. Lack of this
> info blocks progress on the issue reported here
> (https://syzkaller.appspot.com/bug?extid=e245f0516ee625aaa412)

That's a good suggestion, thanks!
I think it should be doable and would indeed simplify debugging of our
reports (even if not for this particular one, judging by the
conversation below :) ).

I've filed https://github.com/google/syzkaller/issues/4200

-- 
Aleksandr

>
> --
> Mateusz Guzik <mjguzik gmail.com>
>