From: Yu Kuai <redacted>
Changes in v3:
- fix a problem in patch 5;
- add patch 12;
Changes in v2:
- replace revert changes for dm-raid with real fixes;
- fix dm-raid5 deadlock that exist for a long time, this deadlock is
triggered because another problem is fixed in raid5, and instead of
deadlock, user will read wrong data before v6.7, patch 9-11;
First regression related to stop sync thread:
The lifetime of sync_thread is designed as following:
1) Decide want to start sync_thread, set MD_RECOVERY_NEEDED, and wake up
daemon thread;
2) Daemon thread detect that MD_RECOVERY_NEEDED is set, then set
MD_RECOVERY_RUNNING and register sync_thread;
3) Execute md_do_sync() for the actual work, if it's done or
interrupted, it will set MD_RECOVERY_DONE and wake up daemone thread;
4) Daemon thread detect that MD_RECOVERY_DONE is set, then clear
MD_RECOVERY_RUNNING and unregister sync_thread;
In v6.7, we fix md/raid to follow this design by commit f52f5c71f3d4
("md: fix stopping sync thread"), however, dm-raid is not considered at
that time, and following test will hang:
shell/integrity-caching.sh
shell/lvconvert-raid-reshape.sh
This patch set fix the broken test by patch 1-4;
- patch 1 fix that step 4) is broken by suspended array;
- patch 2 fix that step 4) is broken by read-only array;
- patch 3 fix that step 3) is broken that md_do_sync() doesn't set
MD_RECOVERY_DONE; Noted that this patch will introdece new problem that
data will be corrupted, which will be fixed in later patches.
- patch 4 fix that setp 1) is broken that sync_thread is register and
MD_RECOVERY_RUNNING is set directly, md/raid behaviour, not related to
dm-raid;
With patch 1-4, the above test won't hang anymore, however, the test
will still fail and complain that ext4 is corrupted;
Second regression related to frozen sync thread:
Noted that for raid456, if reshape is interrupted, then call
"pers->start_reshape" will corrupt data. And dm-raid rely on md_do_sync()
doesn't set MD_RECOVERY_DONE so that new sync_thread won't be registered,
and patch 3 just break this.
- Patch 5-6 fix this problem by interrupting reshape and frozen
sync_thread in dm_suspend(), then unfrozen and continue reshape in
dm_resume(). It's verified that dm-raid tests won't complain that
ext4 is corrupted anymore.
- Patch 7 fix the problem that raid_message() call
md_reap_sync_thread() directly, without holding 'reconfig_mutex'.
Last regression related to dm-raid456 IO concurrent with reshape:
For raid456, if reshape is still in progress, then IO across reshape
position will wait for reshape to make progress. However, for dm-raid,
in following cases reshape will never make progress hence IO will hang:
1) the array is read-only;
2) MD_RECOVERY_WAIT is set;
3) MD_RECOVERY_FROZEN is set;
After commit c467e97f079f ("md/raid6: use valid sector values to determine
if an I/O should wait on the reshape") fix the problem that IO across
reshape position doesn't wait for reshape, the dm-raid test
shell/lvconvert-raid-reshape.sh start to hang at raid5_make_request().
For md/raid, the problem doesn't exist because:
1) If array is read-only, it can switch to read-write by ioctl/sysfs;
2) md/raid never set MD_RECOVERY_WAIT;
3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold
'reconfig_mutex' anymore, it can be cleared and reshape can continue by
sysfs api 'sync_action'.
However, I'm not sure yet how to avoid the problem in dm-raid yet.
- patch 9-11 fix this problem by detecting the above 3 cases in
dm_suspend(), and fail those IO directly.
If user really meet the IO error, then it means they're reading the wrong
data before c467e97f079f. And it's safe to read/write the array after
reshape make progress successfully.
There are also some other minor changes: patch 8 and patch 12;
Yu Kuai (12):
md: don't ignore suspended array in md_check_recovery()
md: don't ignore read-only array in md_check_recovery()
md: make sure md_do_sync() will set MD_RECOVERY_DONE
md: don't register sync_thread for reshape directly
md: export helpers to stop sync_thread
dm-raid: really frozen sync_thread during suspend
md/dm-raid: don't call md_reap_sync_thread() directly
dm-raid: remove mddev_suspend/resume()
dm-raid: add a new helper prepare_suspend() in md_personality
md: export helper md_is_rdwr()
md/raid456: fix a deadlock for dm-raid456 while io concurrent with
reshape
dm-raid: fix lockdep waring in "pers->hot_add_disk"
drivers/md/dm-raid.c | 78 ++++++++++++++++++++++++-----------
drivers/md/md.c | 96 ++++++++++++++++++++++++++++----------------
drivers/md/md.h | 16 ++++++++
drivers/md/raid10.c | 16 +-------
drivers/md/raid5.c | 61 +++++++++++++++-------------
5 files changed, 167 insertions(+), 100 deletions(-)
--
2.39.2
From: Yu Kuai <redacted>
mddev_suspend() never stop sync_thread, hence it doesn't make sense to
ignore suspended array in md_check_recovery(), which might cause
sync_thread can't be unregistered.
After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:
1) suspend the array:
raid_postsuspend
mddev_suspend
2) stop the array:
raid_dtr
md_stop
__md_stop_writes
stop_sync_thread
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
md_wakeup_thread_directly(mddev->sync_thread);
wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
3) sync thread done:
md_do_sync
set_bit(MD_RECOVERY_DONE, &mddev->recovery);
md_wakeup_thread(mddev->thread);
4) daemon thread can't unregister sync thread:
md_check_recovery
if (mddev->suspended)
return; -> return directly
md_read_sync_thread
clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
-> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang;
This problem is not just related to dm-raid, fix it by ignoring
suspended array in md_check_recovery(). And follow up patches will
improve dm-raid better to frozen sync thread during suspend.
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Closes: https://lore.kernel.org/all/8fb335e-6d2c-dbb5-d7-ded8db5145a@redhat.com/
Fixes: 68866e425be2 ("MD: no sync IO while suspended")
Fixes: f52f5c71f3d4 ("md: fix stopping sync thread")
Signed-off-by: Yu Kuai <redacted>
---
drivers/md/md.c | 3 ---
1 file changed, 3 deletions(-)
From: Yu Kuai <redacted>
Usually if the array is not read-write, md_check_recovery() won't
register new sync_thread in the first place. And if the array is
read-write and sync_thread is registered, md_set_readonly() will
unregister sync_thread before setting the array read-only. md/raid
follow this behavior hence there is no problem.
After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:
1) array is read-only. dm-raid update super block:
rs_update_sbs
ro = mddev->ro
mddev->ro = 0
-> set array read-write
md_update_sb
2) register new sync thread concurrently.
3) dm-raid set array back to read-only:
rs_update_sbs
mddev->ro = ro
4) stop the array:
raid_dtr
md_stop
stop_sync_thread
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
md_wakeup_thread_directly(mddev->sync_thread);
wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
5) sync thread done:
md_do_sync
set_bit(MD_RECOVERY_DONE, &mddev->recovery);
md_wakeup_thread(mddev->thread);
6) daemon thread can't unregister sync thread:
md_check_recovery
if (!md_is_rdwr(mddev) &&
!test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))
return;
-> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;
The root cause is that dm-raid manipulate 'mddev->ro' by itself,
however, dm-raid really should stop sync thread before setting the
array read-only. Unfortunately, I need to read more code before I
can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix
the problem the easy way for now to prevent dm-raid regression.
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Closes: https://lore.kernel.org/all/9801e40-8ac7-e225-6a71-309dcf9dc9aa@redhat.com/
Fixes: ecbfb9f118bc ("dm raid: add raid level takeover support")
Fixes: f52f5c71f3d4 ("md: fix stopping sync thread")
Signed-off-by: Yu Kuai <redacted>
---
drivers/md/md.c | 31 ++++++++++++++++++-------------
1 file changed, 18 insertions(+), 13 deletions(-)
From: Yu Kuai <redacted>
stop_sync_thread() will interrupt md_do_sync(), and md_do_sync() must
set MD_RECOVERY_DONE, so that follow up md_check_recovery() will
unregister sync_thread, clear MD_RECOVERY_RUNNING and wake up
stop_sync_thread().
If MD_RECOVERY_WAIT is set or the array is read-only, md_do_sync() will
return without setting MD_RECOVERY_DONE, and after commit f52f5c71f3d4
("md: fix stopping sync thread"), dm-raid switch from
md_reap_sync_thread() to stop_sync_thread() to unregister sync_thread
from md_stop() and md_stop_writes(), causing the test
shell/lvconvert-raid-reshape.sh hang.
We shouldn't switch back to md_reap_sync_thread() because it's
problematic in the first place. Fix the problem by making sure
md_do_sync() will set MD_RECOVERY_DONE.
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Closes: https://lore.kernel.org/all/ece2b06f-d647-6613-a534-ff4c9bec1142@redhat.com/
Fixes: d5d885fd514f ("md: introduce new personality funciton start()")
Fixes: 5fd6c1dce06e ("[PATCH] md: allow checkpoint of recovery with version-1 superblock")
Fixes: f52f5c71f3d4 ("md: fix stopping sync thread")
Signed-off-by: Yu Kuai <redacted>
---
drivers/md/md.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
@@ -8788,12 +8788,16 @@ void md_do_sync(struct md_thread *thread)intret;/* just incase thread restarts... */-if(test_bit(MD_RECOVERY_DONE,&mddev->recovery)||-test_bit(MD_RECOVERY_WAIT,&mddev->recovery))+if(test_bit(MD_RECOVERY_DONE,&mddev->recovery))return;-if(!md_is_rdwr(mddev)){/* never try to sync a read-only array */++if(test_bit(MD_RECOVERY_INTR,&mddev->recovery))+gotoskip;++if(test_bit(MD_RECOVERY_WAIT,&mddev->recovery)||+!md_is_rdwr(mddev)){/* never try to sync a read-only array */set_bit(MD_RECOVERY_INTR,&mddev->recovery);-return;+gotoskip;}if(mddev_is_clustered(mddev)){
From: Yu Kuai <redacted>
Currently, if reshape is interrupted, then reassemble the array will
register sync_thread directly from pers->run(), in this case
'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee
that md_do_sync() will be executed, hence stop_sync_thread() will hang
because 'MD_RECOVERY_RUNNING' can't be cleared.
Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE,
however, following hang can still be triggered by dm-raid test
shell/lvconvert-raid-reshape.sh occasionally:
[root@fedora ~]# cat /proc/1982/stack
[<0>] stop_sync_thread+0x1ab/0x270 [md_mod]
[<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod]
[<0>] raid_presuspend+0x1e/0x70 [dm_raid]
[<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod]
[<0>] __dm_destroy+0x2a5/0x310 [dm_mod]
[<0>] dm_destroy+0x16/0x30 [dm_mod]
[<0>] dev_remove+0x165/0x290 [dm_mod]
[<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod]
[<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod]
[<0>] vfs_ioctl+0x21/0x60
[<0>] __x64_sys_ioctl+0xb9/0xe0
[<0>] do_syscall_64+0xc6/0x230
[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
Meanwhile mddev->recovery is:
MD_RECOVERY_RUNNING |
MD_RECOVERY_INTR |
MD_RECOVERY_RESHAPE |
MD_RECOVERY_FROZEN
Fix this problem by remove the code to register sync_thread directly
from raid10 and raid5. And let md_check_recovery() to register
sync_thread.
Fixes: f67055780caa ("[PATCH] md: Checkpoint and allow restart of raid5 reshape")
Fixes: f52f5c71f3d4 ("md: fix stopping sync thread")
Signed-off-by: Yu Kuai <redacted>
---
drivers/md/md.c | 5 ++++-
drivers/md/raid10.c | 16 ++--------------
drivers/md/raid5.c | 29 ++---------------------------
3 files changed, 8 insertions(+), 42 deletions(-)
@@ -7936,11 +7936,7 @@ static int raid5_run(struct mddev *mddev)clear_bit(MD_RECOVERY_SYNC,&mddev->recovery);clear_bit(MD_RECOVERY_CHECK,&mddev->recovery);set_bit(MD_RECOVERY_RESHAPE,&mddev->recovery);-set_bit(MD_RECOVERY_RUNNING,&mddev->recovery);-rcu_assign_pointer(mddev->sync_thread,-md_register_thread(md_do_sync,mddev,"reshape"));-if(!mddev->sync_thread)-gotoabort;+set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);}/* Ok, everything is just fine now */
@@ -8506,29 +8502,8 @@ static int raid5_start_reshape(struct mddev *mddev)clear_bit(MD_RECOVERY_CHECK,&mddev->recovery);clear_bit(MD_RECOVERY_DONE,&mddev->recovery);set_bit(MD_RECOVERY_RESHAPE,&mddev->recovery);-set_bit(MD_RECOVERY_RUNNING,&mddev->recovery);-rcu_assign_pointer(mddev->sync_thread,-md_register_thread(md_do_sync,mddev,"reshape"));-if(!mddev->sync_thread){-mddev->recovery=0;-spin_lock_irq(&conf->device_lock);-write_seqcount_begin(&conf->gen_lock);-mddev->raid_disks=conf->raid_disks=conf->previous_raid_disks;-mddev->new_chunk_sectors=-conf->chunk_sectors=conf->prev_chunk_sectors;-mddev->new_layout=conf->algorithm=conf->prev_algo;-rdev_for_each(rdev,mddev)-rdev->new_data_offset=rdev->data_offset;-smp_wmb();-conf->generation--;-conf->reshape_progress=MaxSector;-mddev->reshape_position=MaxSector;-write_seqcount_end(&conf->gen_lock);-spin_unlock_irq(&conf->device_lock);-return-EAGAIN;-}+set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);conf->reshape_checkpoint=jiffies;-md_wakeup_thread(mddev->sync_thread);md_new_event();return0;}
From: Yu Kuai <redacted>
The new heleprs will be used in dm-raid in later patches to fix
regressions and prevent calling md_reap_sync_thread() directly.
Signed-off-by: Yu Kuai <redacted>
---
drivers/md/md.c | 33 +++++++++++++++++++++++++++++++--
drivers/md/md.h | 3 +++
2 files changed, 34 insertions(+), 2 deletions(-)
From: Yu Kuai <redacted>
1) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen,
it only prevent new sync_thread to start, and it can't stop the
running sync thread;
2) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use
it as condition for md_stop_writes() in raid_postsuspend() doesn't
look correct.
3) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime,
and if MD_RECOVERY_FROZEN is cleared while the array is suspended,
new sync_thread can start unexpected.
Fix above problems by using the new helper to suspend the array during
suspend, also disallow raid_message() to change sync_thread status
during suspend.
Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), the
test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(),
and with previous fixes, the test won't hang there anymore, however, the
test will still fail and complain that ext4 is corrupted. And with this
patch, the test won't hang due to stop_sync_thread() or fail due to ext4
is corrupted anymore. However, there is still a deadlock related to
dm-raid456 that will be fixed in following patches.
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Closes: https://lore.kernel.org/all/e5e8afe2-e9a8-49a2-5ab0-958d4065c55e@redhat.com/
Fixes: 1af2048a3e87 ("dm raid: fix deadlock caused by premature md_stop_writes()")
Fixes: 9dbd1aa3a81c ("dm raid: add reshaping support to the target")
Fixes: f52f5c71f3d4 ("md: fix stopping sync thread")
Signed-off-by: Yu Kuai <redacted>
---
drivers/md/dm-raid.c | 38 +++++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 9 deletions(-)
@@ -3240,11 +3240,12 @@ static int raid_ctr(struct dm_target *ti, unsigned int argc, char **argv)rs->md.ro=1;rs->md.in_sync=1;-/* Keep array frozen until resume. */-set_bit(MD_RECOVERY_FROZEN,&rs->md.recovery);-/* Has to be held on running the array */mddev_suspend_and_lock_nointr(&rs->md);++/* Keep array frozen until resume. */+md_frozen_sync_thread(&rs->md);+r=md_run(&rs->md);rs->md.in_sync=0;/* Assume already marked dirty */if(r){
@@ -3722,6 +3723,9 @@ static int raid_message(struct dm_target *ti, unsigned int argc, char **argv,if(!mddev->pers||!mddev->pers->sync_request)return-EINVAL;+if(test_bit(RT_FLAG_RS_SUSPENDED,&rs->runtime_flags))+return-EBUSY;+if(!strcasecmp(argv[0],"frozen"))set_bit(MD_RECOVERY_FROZEN,&mddev->recovery);else
@@ -3791,15 +3795,31 @@ static void raid_io_hints(struct dm_target *ti, struct queue_limits *limits)blk_limits_io_opt(limits,chunk_size_bytes*mddev_data_stripes(rs));}+staticvoidraid_presuspend(structdm_target*ti)+{+structraid_set*rs=ti->private;++mddev_lock_nointr(&rs->md);+md_frozen_sync_thread(&rs->md);+mddev_unlock(&rs->md);+}++staticvoidraid_presuspend_undo(structdm_target*ti)+{+structraid_set*rs=ti->private;++mddev_lock_nointr(&rs->md);+md_unfrozen_sync_thread(&rs->md);+mddev_unlock(&rs->md);+}+staticvoidraid_postsuspend(structdm_target*ti){structraid_set*rs=ti->private;if(!test_and_set_bit(RT_FLAG_RS_SUSPENDED,&rs->runtime_flags)){/* Writes have to be stopped before suspending to avoid deadlocks. */-if(!test_bit(MD_RECOVERY_FROZEN,&rs->md.recovery))-md_stop_writes(&rs->md);-+md_stop_writes(&rs->md);mddev_suspend(&rs->md,false);}}
@@ -4012,8 +4032,6 @@ static int raid_preresume(struct dm_target *ti)}/* Check for any resize/reshape on @rs and adjust/initiate */-/* Be prepared for mddev_resume() in raid_resume() */-set_bit(MD_RECOVERY_FROZEN,&mddev->recovery);if(mddev->recovery_cp&&mddev->recovery_cp<MaxSector){set_bit(MD_RECOVERY_REQUESTED,&mddev->recovery);mddev->resync_min=mddev->recovery_cp;
From: Yu Kuai <redacted>
Currently md_reap_sync_thread() is called from raid_message() directly
without holding 'reconfig_mutex', this is definitely unsafe because
md_reap_sync_thread() can change many fields that is protected by
'reconfig_mutex'.
However, hold 'reconfig_mutex' here is still problematic because this
will cause deadlock, for example, commit 130443d60b1b ("md: refactor
idle/frozen_sync_thread() to fix deadlock").
Fix this problem by using stop_sync_thread() to unregister sync_thread,
like md/raid did.
Fixes: be83651f0050 ("DM RAID: Add message/status support for changing sync action")
Signed-off-by: Yu Kuai <redacted>
---
drivers/md/dm-raid.c | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
From: Yu Kuai <redacted>
dm_suspend() already make sure that no new IO can be issued and will
wait for all dispatched IO to be done. There is no need to call
mddev_suspend() to make sure that again.
Signed-off-by: Yu Kuai <redacted>
---
drivers/md/dm-raid.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
@@ -3241,7 +3241,7 @@ static int raid_ctr(struct dm_target *ti, unsigned int argc, char **argv)rs->md.in_sync=1;/* Has to be held on running the array */-mddev_suspend_and_lock_nointr(&rs->md);+mddev_lock_nointr(&rs->md);/* Keep array frozen until resume. */md_frozen_sync_thread(&rs->md);
@@ -3825,11 +3825,9 @@ static void raid_postsuspend(struct dm_target *ti){structraid_set*rs=ti->private;-if(!test_and_set_bit(RT_FLAG_RS_SUSPENDED,&rs->runtime_flags)){+if(!test_and_set_bit(RT_FLAG_RS_SUSPENDED,&rs->runtime_flags))/* Writes have to be stopped before suspending to avoid deadlocks. */md_stop_writes(&rs->md);-mddev_suspend(&rs->md,false);-}}staticvoidattempt_restore_of_faulty_devices(structraid_set*rs)
From: Yu Kuai <redacted>
The lockdep assert is added by commit a448af25becf ("md/raid10: remove
rcu protection to access rdev from conf") in print_conf(). And I didn't
notice that dm-raid is calling "pers->hot_add_disk" without holding
'reconfig_mutex'.
"pers->hot_add_disk" read and write many fields that is protected by
'reconfig_mutex', and raid_resume() already grab the lock in other
contex. Hence fix this problem by protecting "pers->host_add_disk"
with the lock.
Fixes: 9092c02d9435 ("DM RAID: Add ability to restore transiently failed devices on resume")
Fixes: a448af25becf ("md/raid10: remove rcu protection to access rdev from conf")
Signed-off-by: Yu Kuai <redacted>
---
drivers/md/dm-raid.c | 2 ++
1 file changed, 2 insertions(+)
From: Yu Kuai <redacted>
For raid456, if reshape is still in progress, then IO across reshape
position will wait for reshape to make progress. However, for dm-raid,
in following cases reshape will never make progress hence IO will hang:
1) the array is read-only;
2) MD_RECOVERY_WAIT is set;
3) MD_RECOVERY_FROZEN is set;
After commit c467e97f079f ("md/raid6: use valid sector values to determine
if an I/O should wait on the reshape") fix the problem that IO across
reshape position doesn't wait for reshape, the dm-raid test
shell/lvconvert-raid-reshape.sh start to hang:
[root@fedora ~]# cat /proc/979/stack
[<0>] wait_woken+0x7d/0x90
[<0>] raid5_make_request+0x929/0x1d70 [raid456]
[<0>] md_handle_request+0xc2/0x3b0 [md_mod]
[<0>] raid_map+0x2c/0x50 [dm_raid]
[<0>] __map_bio+0x251/0x380 [dm_mod]
[<0>] dm_submit_bio+0x1f0/0x760 [dm_mod]
[<0>] __submit_bio+0xc2/0x1c0
[<0>] submit_bio_noacct_nocheck+0x17f/0x450
[<0>] submit_bio_noacct+0x2bc/0x780
[<0>] submit_bio+0x70/0xc0
[<0>] mpage_readahead+0x169/0x1f0
[<0>] blkdev_readahead+0x18/0x30
[<0>] read_pages+0x7c/0x3b0
[<0>] page_cache_ra_unbounded+0x1ab/0x280
[<0>] force_page_cache_ra+0x9e/0x130
[<0>] page_cache_sync_ra+0x3b/0x110
[<0>] filemap_get_pages+0x143/0xa30
[<0>] filemap_read+0xdc/0x4b0
[<0>] blkdev_read_iter+0x75/0x200
[<0>] vfs_read+0x272/0x460
[<0>] ksys_read+0x7a/0x170
[<0>] __x64_sys_read+0x1c/0x30
[<0>] do_syscall_64+0xc6/0x230
[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
This is because reshape can't make progress.
For md/raid, the problem doesn't exist because register new sync_thread
doesn't rely on the IO to be done any more:
1) If array is read-only, it can switch to read-write by ioctl/sysfs;
2) md/raid never set MD_RECOVERY_WAIT;
3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold
'reconfig_mutex', hence it can be cleared and reshape can continue by
sysfs api 'sync_action'.
However, I'm not sure yet how to avoid the problem in dm-raid yet. This
patch detect the above 3 cases in dm_suspend(), and fail those IO
directly. If user really meet the IO error, then it means they're
reading the wrong data before c467e97f079f. And it's safe to read/write
the array after reshape make progress successfully.
Signed-off-by: Yu Kuai <redacted>
---
drivers/md/md.h | 2 +-
drivers/md/raid5.c | 32 +++++++++++++++++++++++++++++++-
2 files changed, 32 insertions(+), 2 deletions(-)
@@ -6025,6 +6033,13 @@ static enum stripe_result make_stripe_request(struct mddev *mddev,out_release:raid5_release_stripe(sh);+out:+if(ret==STRIPE_SCHEDULE_AND_RETRY&&!mddev->gendisk&&+reshape_disabled(mddev)){+bi->bi_status=BLK_STS_IOERR;+ret=STRIPE_FAIL;+pr_err("dm-raid456: io failed across reshape position while reshape can't make progress");+}returnret;}
@@ -8909,6 +8924,18 @@ static int raid5_start(struct mddev *mddev)returnr5l_start(conf->log);}+/*+*Thisisonlyusedfordm-raid456,calleralreadyfrozensync_thread,hence+*ifrehsapeisstillinprogress,iothatiswaitingforreshapecanneverbe+*donenow,hencewakeupandhandlethoseIO.+*/+staticvoidraid5_prepare_suspend(structmddev*mddev)+{+structr5conf*conf=mddev->private;++wake_up(&conf->wait_for_overlap);+}+staticstructmd_personalityraid6_personality={.name="raid6",