aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/md/dm-stripe.c
diff options
context:
space:
mode:
authorJun'ichi Nomura <j-nomura@ce.jp.nec.com>2007-10-19 22:38:43 +0100
committerAlasdair G Kergon <agk@redhat.com>2007-10-20 02:01:05 +0100
commitae9da83f6d800fe1f3b23bfbc8f7222ad1c5bb74 (patch)
tree18ec2683dd90399f09d41725bdc253a7b335bf0d /drivers/md/dm-stripe.c
parent79662d1ea37392651f2cff08626cab6a40ba3adc (diff)
downloadkernel_goldelico_gta04-ae9da83f6d800fe1f3b23bfbc8f7222ad1c5bb74.zip
kernel_goldelico_gta04-ae9da83f6d800fe1f3b23bfbc8f7222ad1c5bb74.tar.gz
kernel_goldelico_gta04-ae9da83f6d800fe1f3b23bfbc8f7222ad1c5bb74.tar.bz2
dm: fix thaw_bdev
This patch fixes a bd_mount_sem counter corruption bug in device-mapper. thaw_bdev() should be called only when freeze_bdev() was called for the device. Otherwise, thaw_bdev() will up bd_mount_sem and corrupt the semaphore counter. struct block_device with the corrupted semaphore may remain in slab cache and be reused later. Attached patch will fix it by calling unlock_fs() instead. unlock_fs() will determine whether it should call thaw_bdev() by checking the device is frozen or not. Easy reproducer is: #!/bin/sh while [ 1 ]; do dmsetup --notable create a dmsetup --nolockfs suspend a dmsetup remove a done It's not easy to see the effect of corrupted semaphore. So I have tested with putting printk below in bdev_alloc_inode(): if (atomic_read(&ei->bdev.bd_mount_sem.count) != 1) printk(KERN_DEBUG "Incorrect semaphore count = %d (%p)\n", atomic_read(&ei->bdev.bd_mount_sem.count), &ei->bdev); Without the patch, I saw something like: Incorrect semaphore count = 17 (f2ab91c0) With the patch, the message didn't appear. The bug was introduced in 2.6.16 with this bug fix: commit d9dde59ba03095e526640988c0fedd75e93bc8b7 Date: Fri Feb 24 13:04:24 2006 -0800 [PATCH] dm: missing bdput/thaw_bdev at removal Need to unfreeze and release bdev otherwise the bdev inode with inconsistent state is reused later and cause problem. and backported to 2.6.15.5. It occurs only in free_dev(), which is called only when the dm device is removed. The buggy code is executed only if md->suspended_bdev is non-NULL and that can happen only when the device was suspended without noflush. Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Cc: stable@kernel.org
Diffstat (limited to 'drivers/md/dm-stripe.c')
0 files changed, 0 insertions, 0 deletions