linux/drivers/md, branch v2.6.26.8

linear: correct disk numbering error check

2008-08-06T16:03:14Z

[ Upstream commit 13864515f7bf6cabd60e63c62e09d311386ae1f1 ] From: "Nikanth Karthikesan" Correct disk numbering problem check. Signed-off-by: Nikanth Karthikesan Signed-off-by: Neil Brown CC: Oliver Pinter Signed-off-by: Greg Kroah-Hartman

Close race in md_probe

2008-08-06T16:03:13Z

[ Upstream commit f48ed538386cb41559282d989354e8f5d442d71c ] There is a possible race in md_probe. If two threads call md_probe for the same device, then one could exit (having checked that ->gendisk exists) before the other has called kobject_init_and_add, thus returning an incomplete kobj which will cause problems when we try to add children to it. So extend the range of protection of disks_mutex slightly to avoid this possibility. Signed-off-by: Neil Brown CC: Oliver Pinter Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-2.6.26' of git://neil.brown.name/md

2008-07-10T16:49:46Z

* 'for-2.6.26' of git://neil.brown.name/md: md: ensure all blocks are uptodate or locked when syncing

md: ensure all blocks are uptodate or locked when syncing

2008-07-10T05:25:18Z

Remove the dubious attempt to prefer 'compute' over 'read'. Not only is it wrong given commit c337869d (md: do not compute parity unless it is on a failed drive), but it can trigger a BUG_ON in handle_parity_checks5(). Cc: Signed-off-by: Dan Williams Signed-off-by: Neil Brown

Merge git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm

2008-07-03T01:55:17Z

* git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm: dm crypt: use cond_resched

dm crypt: use cond_resched

2008-07-02T08:34:28Z

Add cond_resched() to prevent monopolising CPU when processing large bios. dm-crypt processes encryption of bios in sector units. If the bio request is big it can spend a long time in the encryption call. Signed-off-by: Milan Broz Tested-by: Yan Li Signed-off-by: Andrew Morton Signed-off-by: Alasdair G Kergon

Fix error paths if md_probe fails.

2008-06-27T22:31:17Z

md_probe can fail (e.g. alloc_disk could fail) without returning an error (as it alway returns NULL). So when we call mddev_find immediately afterwards, we need to check that md_probe actually succeeded. This means checking that mdev->gendisk is non-NULL. cc: Cc: Dave Jones Signed-off-by: Neil Brown

Don't acknowlege that stripe-expand is complete until it really is.

2008-06-27T22:31:14Z

We shouldn't acknowledge that a stripe has been expanded (When reshaping a raid5 by adding a device) until the moved data has actually been written out. However we are currently acknowledging (by calling md_done_sync) when the POST_XOR is complete and before the write. So track in s.locked whether there are pending writes, and don't call md_done_sync yet if there are. Note: we all set R5_LOCKED on devices which are are about to read from. This probably isn't technically necessary, but is usually done when writing a block, and justifies the use of s.locked here. This bug can lead to a crash if an array is stopped while an reshape is in progress. Cc: Signed-off-by: Neil Brown

Ensure interrupted recovery completed properly (v1 metadata plus bitmap)

2008-06-27T22:30:52Z

If, while assembling an array, we find a device which is not fully in-sync with the array, it is important to set the "fullsync" flags. This is an exact analog to the setting of this flag in hot_add_disk methods. Currently, only v1.x metadata supports having devices in an array which are not fully in-sync (it keep track of how in sync they are). The 'fullsync' flag only makes a difference when a write-intent bitmap is being used. In this case it tells recovery to ignore the bitmap and recovery all blocks. This fix is already in place for raid1, but not raid5/6 or raid10. So without this fix, a raid1 ir raid4/5/6 array with version 1.x metadata and a write intent bitmaps, that is stopped in the middle of a recovery, will appear to complete the recovery instantly after it is reassembled, but the recovery will not be correct. If you might have an array like that, issueing echo repair > /sys/block/mdXX/md/sync_action will make sure recovery completes properly. Cc: Signed-off-by: Neil Brown

md: do not compute parity unless it is on a failed drive

2008-06-06T18:29:08Z

If a block is computed (rather than read) then a check/repair operation may be lead to believe that the data on disk is correct, when infact it isn't. So only compute blocks for failed devices. This issue has been around since at least 2.6.12, but has become harder to hit in recent kernels since most reads bypass the cache. echo repair > /sys/block/mdN/md/sync_action will set the parity blocks to the correct state. Cc: Signed-off-by: Dan Williams Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds