From patchwork Mon Jun 22 17:46:48 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vivek Goyal X-Patchwork-Id: 6657371 X-Patchwork-Delegate: snitzer@redhat.com Return-Path: X-Original-To: patchwork-dm-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 256AC9F380 for ; Mon, 22 Jun 2015 17:56:05 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 467CD205BC for ; Mon, 22 Jun 2015 17:56:04 +0000 (UTC) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3DB76205B9 for ; Mon, 22 Jun 2015 17:56:03 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5MHkoFb004336; Mon, 22 Jun 2015 13:46:51 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t5MHknA4006544 for ; Mon, 22 Jun 2015 13:46:49 -0400 Received: from horse.redhat.com (dhcp-25-44.bos.redhat.com [10.18.25.44]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5MHkm0s032210; Mon, 22 Jun 2015 13:46:49 -0400 Received: by horse.redhat.com (Postfix, from userid 10451) id 9ED04202085; Mon, 22 Jun 2015 13:46:48 -0400 (EDT) Date: Mon, 22 Jun 2015 13:46:48 -0400 From: Vivek Goyal To: Christoph Hellwig Message-ID: <20150622174648.GA2965@redhat.com> References: <20150618165713.GB19417@two.firstfloor.org> <20150618180408.GD2321@redhat.com> <20150618180804.GC19417@two.firstfloor.org> <20150618181619.GE2321@redhat.com> <20150618190815.GA6390@redhat.com> <20150618192821.GA4027@redhat.com> <20150619064721.GA1183@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150619064721.GA1183@lst.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-loop: dm-devel@redhat.com Cc: Tejun Heo , dm-devel@redhat.com, Andi Kleen , linux-kernel@vger.kernel.org, Mike Snitzer Subject: Re: [dm-devel] WARNING: at fs/block_dev.c:5 when removing LV on removed device X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk Reply-To: device-mapper development List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 Signed-off-by: Vivek Goyal Reviewed-by: Christoph Hellwig --- fs/block_dev.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel 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)