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]

Date:   Thu, 21 Sep 2023 10:38:17 +1000
From:   Dave Chinner <david@...morbit.com>
To:     Aleksandr Nogikh <nogikh@...gle.com>
Cc:     Christoph Hellwig <hch@....de>,
        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
Subject: Re: [syzbot] [xfs?] INFO: task hung in clean_bdev_aliases

On Wed, Sep 20, 2023 at 10:56:56AM +0200, Aleksandr Nogikh wrote:
> # set subsystems: iomap

No. As I said when I originally reassigned this from XFS to the
block subsystem, this is a regression caused by changes to the block
device code. Just because that overall change was to use iomap for
block devices, that doesn't make it an iomap regression or the
responsibility of XFS or iomap maintainers to triage and fix this
block device regression.

> On Fri, Sep 8, 2023 at 10:28 AM Christoph Hellwig <hch@....de> wrote:
> >
> > On Wed, Sep 06, 2023 at 07:20:15PM +0200, Aleksandr Nogikh wrote:
> > >
> > > 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.

Which is exactly what Christoph also said.

Please don't conflate a discussion about the incorrect assignment
by syzbot (i.e. associating iomap with XFS because of a shared
mailing list) with the actual problem that was initially reported.

So, set this back to the block subsystem where it actually belongs.

#syz set subsystems: block

-Dave
-- 
Dave Chinner
david@...morbit.com