@@ -50,12 +50,21 @@ struct block_device *I_BDEV(struct inode *inode)
}
EXPORT_SYMBOL(I_BDEV);
-static void bdev_write_inode(struct inode *inode)
+static void bdev_write_inode(struct block_device *bdev)
{
+ struct inode *inode = bdev->bd_inode;
+ int ret;
+
spin_lock(&inode->i_lock);
while (inode->i_state & I_DIRTY) {
spin_unlock(&inode->i_lock);
- WARN_ON_ONCE(write_inode_now(inode, true));
+ ret = write_inode_now(inode, true);
+ if (ret) {
+ char name[BDEVNAME_SIZE];
+ pr_warn_ratelimited("VFS: Dirty inode writeback failed "
+ "for block device %s (err=%d).\n",
+ bdevname(bdev, name), ret);
+ }
spin_lock(&inode->i_lock);
}
spin_unlock(&inode->i_lock);
@@ -1504,7 +1513,7 @@ static void __blkdev_put(struct block_device *bdev, fmode_t mode, int for_part)
* ->release can cause the queue to disappear, so flush all
* dirty data before.
*/
- bdev_write_inode(bdev->bd_inode);
+ bdev_write_inode(bdev);
}
if (bdev->bd_contains == bdev) {
if (disk->fops->release)
Hi, Dave, I find another warning below: Modules linked in: CPU: 4 PID: 986 Comm: dd Not tainted 4.1.18+ #9 Hardware name: Hisilicon PhosphorHi1382 EVB (DT) Call trace: [<ffffffc000089610>] dump_backtrace+0x0/0x140 [<ffffffc000089770>] show_stack+0x20/0x30 [<ffffffc0007a0eb0>] dump_stack+0x90/0xb0 [<ffffffc0000bdd38>] warn_slowpath_common+0xa8/0xe0 [<ffffffc0000bde64>] warn_slowpath_null+0x24/0x30 [<ffffffc00024abc0>] mark_buffer_dirty+0xe0/0xf0 [<ffffffc0002b8554>] group_adjust_blocks.isra.5.part.6+0x74/0x90 [<ffffffc0002b9bb4>] ext2_new_blocks+0x524/0x5c0 [<ffffffc0002bd46c>] ext2_get_blocks+0x20c/0x9c0 [<ffffffc0002bdc5c>] ext2_get_block+0x3c/0x70 [<ffffffc00024dea4>] __block_write_begin+0x204/0x470 [<ffffffc00024e164>] block_write_begin+0x54/0xa0 [<ffffffc0002bd188>] ext2_write_begin+0x48/0x90 [<ffffffc0001a5eb0>] generic_perform_write+0xc0/0x1b0 [<ffffffc0001a7280>] __generic_file_write_iter+0x160/0x1a0 [<ffffffc0001a7398>] generic_file_write_iter+0xd8/0x210 [<ffffffc0002139fc>] __vfs_write+0xac/0x120 [<ffffffc0002143bc>] vfs_write+0x9c/0x1b0 [<ffffffc000214f70>] SyS_write+0x50/0xb0 ---[ end trace 1a476a49530de7bc ]--- And I also find a warn like this has been fixed before. commit dbd3ca50753e70e09cad747dce23b1a7683a3342 Author: Vivek Goyal <vgoyal@redhat.com> Date: Mon Nov 9 09:23:40 2015 -0700 fs/block_dev.c: Remove WARN_ON() when inode writeback fails If a block device is hot removed and later last reference to device is put, we try to writeback the dirty inode. But device is gone and that writeback fails. Currently we do a WARN_ON() which does not seem to be the right thing. Convert it to a ratelimited kernel warning. Reported-by: Andi Kleen <andi@firstfloor.org> Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Acked-by: Tejun Heo <tj@kernel.org> [jmoyer@redhat.com: get rid of unnecessary name initialization, 80 cols] Signed-off-by: Jeff Moyer <jmoyer@redhat.com> Signed-off-by: Jens Axboe <axboe@fb.com> (END) May be, the three warnings should be fixed together? ? 2016/3/2 5:34, Dave Chinner ??: > On Mon, Feb 29, 2016 at 03:03:54PM +0800, zhangaihua1@huawei.com wrote: >> From: zhangaihua <zhangaihua1@huawei.com> >> >> When a disk is ejected, we try to do the operation 'ls', it will fails >> because device is gone. >> >> Currently we do a WARN() which does not seem to be the right thing. >> Convert it to a ratelimited kernel warning. > > I don't think this is a good idea - the stack trace is required to > determine what code has failed to detect that the device has gone > and is trying to continue onwards without handling errors correctly. > > IMO, iterate_dir() should be fixed to do the right thing when > errors have occurred.... > > Cheers, > > Dave. > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html