kernel/git/stable/linux.git/drivers/md, branch linux-2.6.31.y

md: Fix unfortunate interaction with evms

2010-01-06T22:26:28+00:00

commit cbd1998377504df005302ac90d49db72a48552a6 upstream. evms configures md arrays by: open device send ioctl close device for each different ioctl needed. Since 2.6.29, the device can disappear after the 'close' unless a significant configuration has happened to the device. The change made by "SET_ARRAY_INFO" can too minor to stop the device from disappearing, but important enough that losing the change is bad. So: make sure SET_ARRAY_INFO sets mddev->ctime, and keep the device active as long as ctime is non-zero (it gets zeroed with lots of other things when the array is stopped). This is suitable for -stable kernels since 2.6.29. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/bitmap: protect against bitmap removal while being updated.

2009-12-18T21:43:25+00:00

commit aa5cbd103887011b4830355f88fb055f9ad2d556 upstream. A write intent bitmap can be removed from an array while the array is active. When this happens, all IO is suspended and flushed before the bitmap is removed. However it is possible that bitmap_daemon_work is still running to clear old bits from the bitmap. If it is, it can dereference the bitmap after it has been freed. So introduce a new mutex to protect bitmap_daemon_work and get it before destroying a bitmap. This is suitable for any current -stable kernel. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md: revert incorrect fix for read error handling in raid1.

2009-12-08T18:22:24+00:00

commit d0e260782c3702a009645c3caa02e381dab8798b upstream. commit 4706b349f was a forward port of a fix that was needed for SLES10. But in fact it is not needed in mainline because the earlier commit dd00a99e7a fixes the same problem in a better way. Further, this commit introduces a bug in the way it interacts with the automatic read-error-correction. If, after a read error is successfully corrected, the same disk is chosen to re-read - the re-read won't be attempted but an error will be returned instead. After reverting that commit, there is the possibility that a read error on a read-only array (where read errors cannot be corrected as that requires a write) will repeatedly read the same device and continue to get an error. So in the "Array is readonly" case, fail the drive immediately on a read error. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid1/raid10: add a cond_resched

2009-12-08T18:20:58+00:00

commit 1d9d52416c0445019ccc1f0fddb9a227456eb61b upstream. During 'check' of a raid1 or raid10 it is possible for the management thread to spend a lot of time running 'memcmp' on blocks from different devices, so make sure the thread has a chance to schedule. raid5d already has a cond_resched (in process_stripe). Reported-By: Lee Howard Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid5: make sure curr_sync_completes is uptodate when reshape starts

2009-12-08T18:20:57+00:00

commit 8dee7211467a56b7eb4e4359efb0aa4a72e1b6f3 upstream. This value is visible through sysfs and is used by mdadm when it manages a reshape (backing up data that is about to be rearranged). So it is important that it is always correct. Current it does not get updated properly when a reshape starts which can cause problems when assembling an array that is in the middle of being reshaped. This is suitable for 2.6.31.y stable kernels. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md: don't clear endpoint for resync when resync is interrupted.

2009-12-08T18:20:56+00:00

commit 24395a85d8efe6eee477ea35c73d045a8dd7a3a1 upstream. If a 'sync_max' has been set (via sysfs), it is wrong to clear it until a resync (or reshape or recovery ...) actually reached that point. So if a resync is interrupted (e.g. by device failure), leave 'resync_max' unchanged. This is particularly important for 'reshape' operations that do not change the size of the array. For such operations mdadm needs to monitor the reshape taking rolling backups of the section being reshaped. If resync_max gets cleared, the reshape can get ahead of mdadm and then the backups that mdadm creates are useless. This is suitable for 2.6.31.y stable kernels. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

dm snapshot: use unsigned integer chunk size

2009-11-10T00:22:08+00:00

commit df96eee679ba28c98cf722fa7c9f4286ee1ed0bd upstream. Use unsigned integer chunk size. Maximum chunk size is 512kB, there won't ever be need to use 4GB chunk size, so the number can be 32-bit. This fixes compiler failure on 32-bit systems with large block devices. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Reviewed-by: Jonathan Brassow Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

dm snapshot: require non zero chunk size by end of ctr

2009-11-10T00:22:07+00:00

commit 3f2412dc85260e5aae7ebb03bf50d5b1407e3083 upstream. If we are creating snapshot with memory-stored exception store, fail if the user didn't specify chunk size. Zero chunk size would probably crash a lot of places in the rest of snapshot code. Signed-off-by: Mikulas Patocka Reviewed-by: Jonathan Brassow Reviewed-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

dm snapshot: lock snapshot while supplying status

2009-11-10T00:22:06+00:00

commit 4c6fff445d7aa753957856278d4d93bcad6e2c14 upstream. This patch locks the snapshot when returning status. It fixes a race when it could return an invalid number of free chunks if someone was simultaneously modifying it. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

dm exception store: fix failed set_chunk_size error path

2009-11-10T00:22:06+00:00

commit 0e8c4e4e3ebb15756ddc4170a88149a2cd323cfe upstream. Properly close the device if failing because of an invalid chunk size. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman