Skip to content
Commit c2fd4c94 authored by NeilBrown's avatar NeilBrown
Browse files

md/raid1: update next_resync under resync_lock.



raise_barrier() uses next_resync as part of its calculations, so it
really should be updated first, instead of afterwards.

next_resync is always used under resync_lock so update it under
resync lock to, just before it is used.  That is safest.

This could cause normal IO and resync IO to interact badly so
it suitable for -stable.

Fixes: 79ef3a8a
cc: stable@vger.kernel.org (v3.13+)
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
parent 23554960
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment