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: <CAGudoHGtPOj-HpA25nAkQFmth0F=6WpMFbaqSuu+b34vd243SQ@mail.gmail.com>
Date:   Mon, 4 Sep 2023 08:09:04 +0200
From:   Mateusz Guzik <mjguzik@...il.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     Dave Chinner <david@...morbit.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        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 9/4/23, Theodore Ts'o <tytso@....edu> wrote:
> On Mon, Sep 04, 2023 at 11:45:03AM +1000, Dave Chinner wrote:
>> Entirely possible - this is syzbot we are talking about here.
>> Especially if reiser or ntfs has been tested back before the logs we
>> have start, as both are known to corrupt memory and/or leak locks
>> when trying to parse corrupt filesystem images that syzbot feeds
>> them.  That's why we largely ignore syzbot reports that involve
>> those filesystems...
>>
>> Unfortunately, the logs from what was being done around when the
>> tasks actually hung are long gone (seems like only the last 20-30s
>> of log activity is reported) so when the hung task timer goes off
>> at 143s, there is nothing left to tell us what might have caused it.
>>
>> IOWs, it's entirely possible that it is a memory corruption that
>> has resulted in a leaked lock somewhere...
>
> ... and this is why I ignore any syzbot report that doesn't have a C
> reproducer.  Life is too short to waste time with what is very likely
> syzbot noise....  And I'd much rather opt out of the gamification of
> syzbot dashboards designed to use dark patterns to guilt developers to
> work on "issues" that very likely have no real impact on real life
> actual user impact, if it might cause developers and maintainers to
> burn out and quit.
>
> Basically, if syzbot won't prioritize things for us, it's encumbent on
> us to prioritize things for our own mental health.  And so syzbot
> issues without a real reproducer are very low on my priority list; I
> have things I can work on that are much more likely to make real world
> impact.  Even ones that have a real reproducer, there are certain
> classes of bugs (e.g., "locking bugs" that require a badly corrupted
> file system, or things that are just denial of service attacks if
> you're too stupid to insert a USB thumb drive found in a parking lock
> --- made worse by GNOME who has decided to default mount any random
> USB thumb drive inserted into a system, even a server system that has
> GNOME installed, thanks to some idiotic decision made by some random
> Red Hat product manager), that I just ignore because I don't have
> infinite amounts of time to coddle stupid Red Hat distro tricks.
>

Hello everyone.

When I first stumbled upon this report I was almost completely
oblivious to syzbot vs fsdevel -- I only knew you guys are not fond of
ntfs reports, which made sense but was not indicating there are much
bigger issues.

Given this and other responses I poked around the history and that
made it apparent there are long-standing non-technical problems going
here, none of which I intend to deal with.

That is to say I'm bailing from this thread.

Cheers and sorry for poking the nest,
-- 
Mateusz Guzik <mjguzik gmail.com>