linux-ext4 - Re: [ext4 io hang] buffered write io hang in balance_dirty

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: <ZEym2Yf1Ud1p+L3R@ovpn-8-24.pek2.redhat.com>
Date:   Sat, 29 Apr 2023 13:10:49 +0800
From:   Ming Lei <ming.lei@...hat.com>
To:     Christoph Hellwig <hch@....de>
Cc:     Theodore Ts'o <tytso@....edu>, Baokun Li <libaokun1@...wei.com>,
        Matthew Wilcox <willy@...radead.org>,
        linux-ext4@...r.kernel.org,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        linux-block@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        Dave Chinner <dchinner@...hat.com>,
        Eric Sandeen <sandeen@...hat.com>,
        Zhang Yi <yi.zhang@...hat.com>,
        yangerkun <yangerkun@...wei.com>, ming.lei@...hat.com
Subject: Re: [ext4 io hang] buffered write io hang in balance_dirty_pages

On Sat, Apr 29, 2023 at 06:40:38AM +0200, Christoph Hellwig wrote:
> On Sat, Apr 29, 2023 at 11:16:14AM +0800, Ming Lei wrote:
> > OK, looks both Dave and you have same suggestion, and IMO, it isn't hard to
> > add one interface for notifying FS, and it can be either one s_ops->shutdown()
> > or shutdown_filesystem(struct super_block *sb).
> 
> It's not that simple.  You need to be able to do that for any device used
> by a file system, not just s_bdev.  This means it needs go into ops
> passed by the bdev owner, which is also needed to propagate this through
> stackable devices.

Not sure if it is needed for non s_bdev , because FS is over stackable device
directly. Stackable device has its own logic for handling underlying disks dead
or deleted, then decide if its own disk needs to be deleted, such as, it is
fine for raid1 to work from user viewpoint if one underlying disk is deleted.

> 
> I have some work on that, but the way how blkdev_get is called in the
> generic mount helpers is a such a mess that I've not been happy with
> the result yet.  Let me see if spending extra time with it will allow
> me to come up with something that doesn't suck.
> 
> > But the main job should be how this interface is implemented in FS/VFS side,
> > so it looks one more FS job, and block layer can call shutdown_filesystem()
> > from del_gendisk() simply.
> 
> This needs to be called from blk_mark_disk_dead for drivers using that,
> and from del_gendisk only if GD_DEAD isn't set yet.

OK, looks you mean the API needs to be called before GD_DEAD is set,
but I am wondering if it makes a difference, given device is already
dead.


Thanks,
Ming