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

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: <20230908082846.GB9560@lst.de>
Date:   Fri, 8 Sep 2023 10:28:46 +0200
From:   Christoph Hellwig <hch@....de>
To:     Aleksandr Nogikh <nogikh@...gle.com>
Cc:     Dave Chinner <david@...morbit.com>,
        syzbot <syzbot+1fa947e7f09e136925b8@...kaller.appspotmail.com>,
        djwong@...nel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org,
        syzkaller-bugs@...glegroups.com, linux-block@...r.kernel.org,
        hch@....de
Subject: Re: [syzbot] [xfs?] INFO: task hung in clean_bdev_aliases

On Wed, Sep 06, 2023 at 07:20:15PM +0200, Aleksandr Nogikh wrote:
> On Tue, Sep 5, 2023 at 11:14 PM 'Dave Chinner' via syzkaller-bugs
> <syzkaller-bugs@...glegroups.com> wrote:
> >
> > [cc linux-block, Christoph]
> >
> > Another iomap-blockdev related issue.
> >
> > #syz set subsystems: block
> >
> > syzbot developers: Please review how you are classifying subsystems,
> > this is the third false XFS classification in 24 hours.
> 
> The reason why syzbot marked this report as xfs is that, per
> MAINTAINERS, fs/iomap/ points to linux-xfs@...r.kernel.org. I can
> adjust the rules syzbot uses so that these are routed to "block".
> 
> But should MAINTAINERS actually also not relate IOMAP FILESYSTEM
> LIBRARY with xfs in this case?

I'd tag it with iomap, as it's a different subsystem just sharing
the mailing list.  We also have iommu@...ts.linux.dev for both the
iommu and dma-mapping subsystems as a similar example.

But what's also important for issues like this is that often the
called library code (in this case iomap) if often not, or only
partially at fault.  So capturing the calling context (in this
case block) might also be useful.

And to get out of these meta discussions:  I'll look into the actual
issues in a bit, I'll try to find time despite travelling.