Message ID | 20090912195839.GG14984@kernel.dk (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
On Sat, Sep 12 2009, Jens Axboe wrote: > 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] > > > |[<c0028dd8>] (unwind_backtrace+0x0/0xdc) from [<c003adb0>] (warn_slowpath_common+0x4c/0x80) > > > |[<c003adb0>] (warn_slowpath_common+0x4c/0x80) from [<c007f2e0>] (bdi_destroy+0x44/0x60) > > > |[<c007f2e0>] (bdi_destroy+0x44/0x60) from [<c012e3a0>] (blk_release_queue+0x3c/0x54) > > > |[<c012e3a0>] (blk_release_queue+0x3c/0x54) from [<c01399a8>] (kobject_release+0x5c/0x74) > > > |[<c01399a8>] (kobject_release+0x5c/0x74) from [<c013a6ac>] (kref_put+0x68/0x7c) > > > |[<c013a6ac>] (kref_put+0x68/0x7c) from [<c01b7098>] (dm_put+0x148/0x178) > > > |[<c01b7098>] (dm_put+0x148/0x178) from [<c01bb82c>] (dev_remove+0x98/0xb4) > > > |[<c01bb82c>] (dev_remove+0x98/0xb4) from [<c01bbec0>] (dm_ctl_ioctl+0x21c/0x29c) > > > |[<c01bbec0>] (dm_ctl_ioctl+0x21c/0x29c) from [<c00a153c>] (vfs_ioctl+0x2c/0x8c) > > > |[<c00a153c>] (vfs_ioctl+0x2c/0x8c) from [<c00a1bac>] (do_vfs_ioctl+0x524/0x590) > > > |[<c00a1bac>] (do_vfs_ioctl+0x524/0x590) from [<c00a1c50>] (sys_ioctl+0x38/0x5c) > > > |[<c00a1c50>] (sys_ioctl+0x38/0x5c) from [<c0023e80>] (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. Though I do wonder why we have dirty inodes there, if dm has ensured that the device has no other openers left. Something to investigate for monday.
On Sun, Sep 13 2009, Sebastian Andrzej Siewior wrote: > * Jens Axboe | 2009-09-12 21:58:40 [+0200]: > > >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. > > That warning goes away but another pops up: Oh right, just goes to show that it's doing this backwards. We need the umount rwsem for WB_SYNC_ALL. I'll look at this tomorrow.
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; }