kernel/linux.git/drivers/md/raid10.c, branch linux-2.6.22.y

md: raid10: fix use-after-free of bio

2007-08-09T21:27:36+00:00

In case of read errors raid10d tries to print a nice error message, unfortunately using data from an already put bio. Signed-off-by: Maik Hampel Acked-By: NeilBrown Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

md: handle writes to broken raid10 arrays gracefully

2007-08-09T21:27:36+00:00

When writing to a broken array, raid10 currently happily emits empty bio lists. IOW, the master bio will never be completed, sending writers to UNINTERRUPTIBLE_SLEEP forever. Signed-off-by: Arne Redlich Acked-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

md: fix two raid10 bugs

2007-06-16T20:16:15+00:00

1/ When resyncing a degraded raid10 which has more than 2 copies of each block, garbage can get synced on top of good data. 2/ We round the wrong way in part of the device size calculation, which can cause confusion. Signed-off-by: Neil Brown Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: fix raid10 recovery problem.

2007-03-01T22:53:36+00:00

There are two errors that can lead to recovery problems with raid10 when used in 'far' more (not the default). Due to a '>' instead of '>=' the wrong block is located which would result in garbage being written to some random location, quite possible outside the range of the device, causing the newly reconstructed device to fail. The device size calculation had some rounding errors (it didn't round when it should) and so recovery would go a few blocks too far which would again cause a write to a random block address and probably a device error. The code for working with device sizes was fairly confused and spread out, so this has been tided up a bit. Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: pass down BIO_RW_SYNC in raid{1,10}

2007-01-12T02:18:21+00:00

md raidX make_request functions strip off the BIO_RW_SYNC flag, thus introducing additional latency. Fixing this in raid1 and raid10 seems to be straightforward enough. For our particular usage case in DRBD, passing this flag improved some initialization time from ~5 minutes to ~5 seconds. Acked-by: NeilBrown Signed-off-by: Lars Ellenberg Acked-by: Jens Axboe Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: Don't assume that READ==0 and WRITE==1 - use the names explicitly

2006-12-13T17:05:48+00:00

Thanks Jens for alerting me to this. Cc: Jens Axboe Cc: Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: fix printk format warnings, seen on powerpc64:

2006-10-28T18:30:52+00:00

drivers/md/raid1.c:1479: warning: long long unsigned int format, long unsigned int arg (arg 4) drivers/md/raid10.c:1475: warning: long long unsigned int format, long unsigned int arg (arg 4) Signed-off-by: Randy Dunlap Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: fix calculation of ->degraded for multipath and raid10

2006-10-21T20:35:05+00:00

Two less-used md personalities have bugs in the calculation of ->degraded (the extent to which the array is degraded). Signed-off-by: Neil Brown Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: define ->congested_fn for raid1, raid10, and multipath

2006-10-03T15:04:18+00:00

raid1, raid10 and multipath don't report their 'congested' status through bdi_*_congested, but should. This patch adds the appropriate functions which just check the 'congested' status of all active members (with appropriate locking). raid1 read_balance should be modified to prefer devices where bdi_read_congested returns false. Then we could use the '&' branch rather than the '|' branch. However that should would need some benchmarking first to make sure it is actually a good idea. Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: Improve locking around error handling

2006-10-03T15:04:18+00:00

The error handling routines don't use proper locking, and so two concurrent errors could trigger a problem. So: - use test-and-set and test-and-clear to synchonise the In_sync bits with the ->degraded count - use the spinlock to protect updates to the degraded count (could use an atomic_t but that would be a bigger change in code, and isn't really justified) - remove un-necessary locking in raid5 Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds