summaryrefslogtreecommitdiffstats
path: root/drivers/scsi/qla4xxx/ql4_os.c
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2009-08-13 10:41:50 +1000
committerNeilBrown <neilb@suse.de>2009-08-13 10:41:50 +1000
commit4d484a4a7a5126410eed5f8dd329a33f6eeed068 (patch)
tree9fe49a23117adc2d475711f39a16c1718bab4b7f /drivers/scsi/qla4xxx/ql4_os.c
parent1a67dde0abba36421a1257d01ba9de2f6d1c160a (diff)
downloadkernel-crypto-4d484a4a7a5126410eed5f8dd329a33f6eeed068.tar.gz
kernel-crypto-4d484a4a7a5126410eed5f8dd329a33f6eeed068.tar.xz
kernel-crypto-4d484a4a7a5126410eed5f8dd329a33f6eeed068.zip
md: allow upper limit for resync/reshape to be set when array is read-only
Normally we only allow the upper limit for a reshape to be decreased when the array not performing a sync/recovery/reshape, otherwise there could be races. But if an array is part-way through a reshape when it is assembled the reshape is started immediately leaving no window to set an upper bound. If the array is started read-only, the reshape will be suspended until the array becomes writable, so that provides a window during which it is perfectly safe to reduce the upper limit of a reshape. So: allow the upper limit (sync_max) to be reduced even if the reshape thread is running, as long as the array is still read-only. Signed-off-by: NeilBrown <neilb@suse.de>
Diffstat (limited to 'drivers/scsi/qla4xxx/ql4_os.c')
0 files changed, 0 insertions, 0 deletions