From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753955AbZILT6j (ORCPT ); Sat, 12 Sep 2009 15:58:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753691AbZILT6h (ORCPT ); Sat, 12 Sep 2009 15:58:37 -0400 Received: from brick.kernel.dk ([93.163.65.50]:60539 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753634AbZILT6h (ORCPT ); Sat, 12 Sep 2009 15:58:37 -0400 Date: Sat, 12 Sep 2009 21:58:40 +0200 From: Jens Axboe To: Sebastian Andrzej Siewior Cc: dm-devel@redhat.com, linux-kernel@vger.kernel.org Subject: Re: recent bdi changes result in WARN_ON on luksClose / dm Message-ID: <20090912195839.GG14984@kernel.dk> References: <20090912111928.GA8013@Chamillionaire.breakpoint.cc> <20090912195212.GF14984@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090912195212.GF14984@kernel.dk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 12 2009, Jens Axboe wrote: > On Sat, Sep 12 2009, Sebastian Andrzej Siewior wrote: > > | Orion:/# cryptsetup luksClose crypto > > |------------[ cut here ]------------ > > |WARNING: at /home/bigeasy/git/cryptodev-2.6/mm/backing-dev.c:637 bdi_destroy+0x44/0x60() > > |Modules linked in: cbc sha256_generic dm_crypt [last unloaded: mv_cesa] > > |[] (unwind_backtrace+0x0/0xdc) from [] (warn_slowpath_common+0x4c/0x80) > > |[] (warn_slowpath_common+0x4c/0x80) from [] (bdi_destroy+0x44/0x60) > > |[] (bdi_destroy+0x44/0x60) from [] (blk_release_queue+0x3c/0x54) > > |[] (blk_release_queue+0x3c/0x54) from [] (kobject_release+0x5c/0x74) > > |[] (kobject_release+0x5c/0x74) from [] (kref_put+0x68/0x7c) > > |[] (kref_put+0x68/0x7c) from [] (dm_put+0x148/0x178) > > |[] (dm_put+0x148/0x178) from [] (dev_remove+0x98/0xb4) > > |[] (dev_remove+0x98/0xb4) from [] (dm_ctl_ioctl+0x21c/0x29c) > > |[] (dm_ctl_ioctl+0x21c/0x29c) from [] (vfs_ioctl+0x2c/0x8c) > > |[] (vfs_ioctl+0x2c/0x8c) from [] (do_vfs_ioctl+0x524/0x590) > > |[] (do_vfs_ioctl+0x524/0x590) from [] (sys_ioctl+0x38/0x5c) > > |[] (sys_ioctl+0x38/0x5c) from [] (ret_fast_syscall+0x0/0x2c) > > |---[ end trace b3c544a14b51605c ]--- > > So dm is killing the queue and associated backing device, while dirty > inodes still exist. That's not very nice. Perhaps dm_lock_for_deletion() > should ensure that the backing is flushed? Don't count this as a real fix, I'll investigate closer on monday. Does the warning go away with this hack? It'll ensure that pending dirty inodes are flushed. diff --git a/drivers/md/dm.c b/drivers/md/dm.c index b4845b1..ead4a9b 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -357,6 +357,17 @@ int dm_open_count(struct mapped_device *md) return atomic_read(&md->open_count); } +static void dm_flush_dirty_io(struct mapped_device *md) +{ + struct writeback_control wbc = { + .bdi = &md->queue->backing_dev_info, + .sync_mode = WB_SYNC_ALL, + .nr_to_write = LONG_MAX, + }; + + bdi_start_writeback(&wbc); +} + /* * Guarantees nothing is using the device before it's deleted. */ @@ -373,6 +384,9 @@ int dm_lock_for_deletion(struct mapped_device *md) spin_unlock(&_minor_lock); + if (!r) + dm_flush_dirty_io(md); + return r; } -- Jens Axboe