kernel/git/stable/linux-stable.git/drivers/md/raid5.c, branch linux-2.6.39.y

md/raid5: fix FUA request handling in ops_run_io()

2011-06-23T22:05:41+00:00

commit b062962edb086011e94ec4d9eb3f6a6d814f2a8f upstream. Commit e9c7469bb4f5 ("md: implment REQ_FLUSH/FUA support") introduced R5_WantFUA flag and set rw to WRITE_FUA in that case. However remaining code still checks whether rw is exactly same as WRITE or not, so FUAed-write ends up with being treated as READ. Fix it. This bug has been present since 2.6.37 and the fix is suitable for any -stable kernel since then. It is not clear why this has not caused more problems. Cc: Tejun Heo Signed-off-by: Namhyung Kim Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid5: fix raid5_set_bi_hw_segments

2011-06-23T22:05:41+00:00

commit 9b2dc8b665932a8e681a7ab3237f60475e75e161 upstream. The @bio->bi_phys_segments consists of active stripes count in the lower 16 bits and processed stripes count in the upper 16 bits. So logical-OR operator should be bitwise one. This bug has been present since 2.6.27 and the fix is suitable for any -stable kernel since then. Fortunately the bad code is only used on error paths and is relatively unlikely to be hit. Signed-off-by: Namhyung Kim Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

raid5: fix build error, sector_t usage

2011-04-21T17:00:00+00:00

Change from unsigned long long to sector_t. This matches its source field. ERROR: "__udivdi3" [drivers/md/raid456.ko] undefined! Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds

md: Fix dev_sectors on takeover from raid0 to raid4/5

2011-04-20T05:38:18+00:00

A raid0 array doesn't set 'dev_sectors' as each device might contribute a different number of sectors. So when converting to a RAID4 or RAID5 we need to set dev_sectors as they need the number. We have already verified that in fact all devices do contribute the same number of sectors, so use that number. Signed-off-by: NeilBrown

md/raid5: remove setting of ->queue_lock

2011-04-20T05:38:07+00:00

We previously needed to set ->queue_lock to match the raid5 device_lock so we could safely use queue_flag_* operations (e.g. for plugging). which test the ->queue_lock is in fact locked. However that need has completely gone away and is unlikely to come back to remove this now-pointless setting. Signed-off-by: NeilBrown

md: incorporate new plugging into raid5.

2011-04-18T08:25:43+00:00

In raid5 plugging is used for 2 things: 1/ collecting writes that require a bitmap update 2/ collecting writes in the hope that we can create full stripes - or at least more-full. We now release these different sets of stripes when plug_cnt is zero. Also in make_request, we call mddev_check_plug to hopefully increase plug_cnt, and wake up the thread at the end if plugging wasn't achieved for some reason. Signed-off-by: NeilBrown

md - remove old plugging code.

2011-04-18T08:25:42+00:00

md has some plugging infrastructure for RAID5 to use because the normal plugging infrastructure required a 'request_queue', and when called from dm, RAID5 doesn't have one of those available. This relied on the ->unplug_fn callback which doesn't exist any more. So remove all of that code, both in md and raid5. Subsequent patches with restore the plugging functionality. Signed-off-by: NeilBrown

md: use new plugging interface for RAID IO.

2011-04-18T08:25:41+00:00

md/raid submits a lot of IO from the various raid threads. So adding start/finish plug calls to those so that some plugging happens. Signed-off-by: NeilBrown

block: remove per-queue plugging

2011-03-10T07:52:07+00:00

Code has been converted over to the new explicit on-stack plugging, and delay users have been converted to use the new API for that. So lets kill off the old plugging along with aops->sync_page(). Signed-off-by: Jens Axboe

md: don't abort checking spares as soon as one cannot be added.

2011-01-31T00:57:43+00:00

As spares can be added manually before a reshape starts, we need to find them all to mark some of them as in_sync. Previously we would abort looking for spares when we found an unallocated spare what could not be added to the array (implying there was no room for new spares). However already-added spares could be later in the list, so we need to keep searching. Signed-off-by: NeilBrown