Re: [PATCH] remove warn when bdi is unregisterd in __mark_inode_dirty().

[Zhang AiHua <zhangaihua1@huawei.com>]

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>

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 0a793c7..bb0dfb1 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -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)
(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.
>