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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxx>
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@xxxxxxxxxxxxxx>
    Signed-off-by: Vivek Goyal <vgoyal@xxxxxxxxxx>
    Acked-by: Tejun Heo <tj@xxxxxxxxxx>
    [jmoyer@xxxxxxxxxx: get rid of unnecessary name initialization, 80 cols]
    Signed-off-by: Jeff Moyer <jmoyer@xxxxxxxxxx>
    Signed-off-by: Jens Axboe <axboe@xxxxxx>

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@xxxxxxxxxx wrote:
From: zhangaihua <zhangaihua1@xxxxxxxxxx>

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux