From: Vivek Goyal <vgoyal@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com, Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>
Subject: Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
Date: Mon, 22 Jun 2015 13:46:48 -0400 [thread overview]
Message-ID: <20150622174648.GA2965@redhat.com> (raw)
In-Reply-To: <20150619064721.GA1183@lst.de>
On Fri, Jun 19, 2015 at 08:47:21AM +0200, Christoph Hellwig wrote:
> On Thu, Jun 18, 2015 at 03:28:21PM -0400, Mike Snitzer wrote:
> > > WARN_ON_ONCE(write_inode_now(inode, true))
> > >
> > > If we failed to write back inode, then warning about it sounds right?
> >
> > A warning is fine.. not a WARN_ON(). Pretty alarming backtrace spew but
> > maybe I'm missing something and DM's blkdev refcount mgmt couldn't
> > trigger this WARN_ON()? I fail to see how to avoid it given the device
> > isn't thre so write_inode_now() fails.
> >
> > > What's wrong with that? Should it be just a kernel log of level KERN_WARN
> > > instead?
> >
> > Ideally, but I honestly don't have all the details paged in my head to
> > say definitively. First need to answer how vitrio-blk isn't hitting
> > this (and DM is). Could it be that __blkdev_put isn't getting called
> > for virtio-blk!?
>
> Just a warnings if fine. In fact we can probably remove that as well
> as it will happen after a hot removal all the time.
[CC Tejun]
Does following patch look good?
Thanks
Vivek
Subject: fs/block_dev.c: Warn on inode writeback failure instead of WARN_ON()
If a block device is hot removed and later last reference to devices
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>
---
fs/block_dev.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
Index: rhvgoyal-linux/fs/block_dev.c
===================================================================
--- rhvgoyal-linux.orig/fs/block_dev.c 2015-06-18 15:54:52.339383237 -0400
+++ rhvgoyal-linux/fs/block_dev.c 2015-06-22 12:55:47.642504742 -0400
@@ -48,12 +48,17 @@ inline struct block_device *I_BDEV(struc
}
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;
+
spin_lock(&inode->i_lock);
while (inode->i_state & I_DIRTY) {
spin_unlock(&inode->i_lock);
- WARN_ON_ONCE(write_inode_now(inode, true));
+ if (write_inode_now(inode, true)) {
+ char name[BDEVNAME_SIZE] = "";
+ pr_warn_ratelimited("VFS: Dirty inode writeback failed for block device %s.\n", bdevname(bdev, name));
+ }
spin_lock(&inode->i_lock);
}
spin_unlock(&inode->i_lock);
@@ -1489,7 +1494,7 @@ static void __blkdev_put(struct block_de
* ->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)
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com, Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>
Subject: Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
Date: Mon, 22 Jun 2015 13:46:48 -0400 [thread overview]
Message-ID: <20150622174648.GA2965@redhat.com> (raw)
In-Reply-To: <20150619064721.GA1183@lst.de>
On Fri, Jun 19, 2015 at 08:47:21AM +0200, Christoph Hellwig wrote:
> On Thu, Jun 18, 2015 at 03:28:21PM -0400, Mike Snitzer wrote:
> > > WARN_ON_ONCE(write_inode_now(inode, true))
> > >
> > > If we failed to write back inode, then warning about it sounds right?
> >
> > A warning is fine.. not a WARN_ON(). Pretty alarming backtrace spew but
> > maybe I'm missing something and DM's blkdev refcount mgmt couldn't
> > trigger this WARN_ON()? I fail to see how to avoid it given the device
> > isn't thre so write_inode_now() fails.
> >
> > > What's wrong with that? Should it be just a kernel log of level KERN_WARN
> > > instead?
> >
> > Ideally, but I honestly don't have all the details paged in my head to
> > say definitively. First need to answer how vitrio-blk isn't hitting
> > this (and DM is). Could it be that __blkdev_put isn't getting called
> > for virtio-blk!?
>
> Just a warnings if fine. In fact we can probably remove that as well
> as it will happen after a hot removal all the time.
[CC Tejun]
Does following patch look good?
Thanks
Vivek
Subject: fs/block_dev.c: Warn on inode writeback failure instead of WARN_ON()
If a block device is hot removed and later last reference to devices
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>
---
fs/block_dev.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
Index: rhvgoyal-linux/fs/block_dev.c
===================================================================
--- rhvgoyal-linux.orig/fs/block_dev.c 2015-06-18 15:54:52.339383237 -0400
+++ rhvgoyal-linux/fs/block_dev.c 2015-06-22 12:55:47.642504742 -0400
@@ -48,12 +48,17 @@ inline struct block_device *I_BDEV(struc
}
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;
+
spin_lock(&inode->i_lock);
while (inode->i_state & I_DIRTY) {
spin_unlock(&inode->i_lock);
- WARN_ON_ONCE(write_inode_now(inode, true));
+ if (write_inode_now(inode, true)) {
+ char name[BDEVNAME_SIZE] = "";
+ pr_warn_ratelimited("VFS: Dirty inode writeback failed for block device %s.\n", bdevname(bdev, name));
+ }
spin_lock(&inode->i_lock);
}
spin_unlock(&inode->i_lock);
@@ -1489,7 +1494,7 @@ static void __blkdev_put(struct block_de
* ->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)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2015-06-22 17:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 16:57 WARNING: at fs/block_dev.c:5 when removing LV on removed device Andi Kleen
2015-06-18 18:04 ` Mike Snitzer
2015-06-18 18:08 ` Andi Kleen
2015-06-18 18:16 ` Mike Snitzer
2015-06-18 19:08 ` [dm-devel] " Vivek Goyal
2015-06-18 19:28 ` Mike Snitzer
2015-06-19 6:47 ` Christoph Hellwig
2015-06-22 17:46 ` Vivek Goyal [this message]
2015-06-22 17:46 ` Vivek Goyal
2015-06-22 17:52 ` Tejun Heo
2015-06-22 17:52 ` Tejun Heo
2015-06-22 17:55 ` Vivek Goyal
2015-06-22 17:55 ` Vivek Goyal
2015-06-23 10:08 ` Christoph Hellwig
2015-06-18 19:53 ` [dm-devel] " Andi Kleen
2015-06-18 21:01 ` Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150622174648.GA2965@redhat.com \
--to=vgoyal@redhat.com \
--cc=andi@firstfloor.org \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=snitzer@redhat.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.