md: be careful when testing resync_max against curr_resync_completed.
While it generally shouldn't happen, it is not impossible for
curr_resync_completed to exceed resync_max.
This can particularly happen when reshaping RAID5 - the current
status isn't copied to curr_resync_completed promptly, so when it
is, it can exceed resync_max.
This happens when the reshape is 'frozen', resync_max is set low,
and reshape is re-enabled.
Taking a difference between two unsigned numbers is always dangerous
anyway, so add a test to behave correctly if
curr_resync_completed > resync_max
Signed-off-by: NeilBrown <neilb@suse.com>
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 19bbdbe..1c27aa1 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -5542,7 +5542,8 @@
sector_nr += reshape_sectors;
retn = reshape_sectors;
finish:
- if ((sector_nr - mddev->curr_resync_completed) * 2
+ if (mddev->curr_resync_completed > mddev->resync_max ||
+ (sector_nr - mddev->curr_resync_completed) * 2
>= mddev->resync_max - mddev->curr_resync_completed) {
/* Cannot proceed until we've updated the superblock... */
wait_event(conf->wait_for_overlap,