summaryrefslogtreecommitdiffstats
path: root/lib/raid6/neon.c
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.com>2015-08-03 13:11:47 +1000
committerNeilBrown <neilb@suse.com>2015-08-03 17:12:44 +1000
commit199dc6ed5179251fa6158a461499c24bdd99c836 (patch)
tree586f5584653e7932239616da52306cd918b249eb /lib/raid6/neon.c
parent25eafe1a813681849ad3fb9effdfdce3e1b4335a (diff)
downloadlinux-199dc6ed5179251fa6158a461499c24bdd99c836.tar.gz
linux-199dc6ed5179251fa6158a461499c24bdd99c836.tar.xz
md/raid0: update queue parameter in a safer location.
When a (e.g.) RAID5 array is reshaped to RAID0, the updating of queue parameters (e.g. max number of sectors per bio) is done in the wrong place. It should be part of ->run, but it is actually part of ->takeover. This means it happens before level_store() calls: blk_set_stacking_limits(&mddev->queue->limits); and so it ineffective. This can lead to errors from underlying devices. So move all the relevant settings out of create_stripe_zones() and into raid0_run(). As this can lead to a bug-on it is suitable for any -stable kernel which supports reshape to RAID0. So 2.6.35 or later. As the bug has been present for five years there is no urgency, so no need to rush into -stable. Fixes: 9af204cf720c ("md: Add support for Raid5->Raid0 and Raid10->Raid0 takeover") Cc: stable@vger.kernel.org (v2.6.35+ - please delay until after -final release). Reported-by: Yi Zhang <yizhan@redhat.com> Signed-off-by: NeilBrown <neilb@suse.com>
Diffstat (limited to 'lib/raid6/neon.c')
0 files changed, 0 insertions, 0 deletions