diff options
author | Guoqing Jiang <gqjiang@suse.com> | 2017-03-14 02:40:20 +0100 |
---|---|---|
committer | Shaohua Li <shli@fb.com> | 2017-03-17 00:55:58 +0100 |
commit | 48df498daf62e1292868005675331929305067f0 (patch) | |
tree | fa449f9bdc074689955e4c6d8f5d62087b619c77 /drivers/scsi/sr_ioctl.c | |
parent | md/r5cache: generate R5LOG_PAYLOAD_FLUSH (diff) | |
download | linux-48df498daf62e1292868005675331929305067f0.tar.xz linux-48df498daf62e1292868005675331929305067f0.zip |
md: move bitmap_destroy to the beginning of __md_stop
Since we have switched to sync way to handle METADATA_UPDATED
msg for md-cluster, then process_metadata_update is depended
on mddev->thread->wqueue.
With the new change, clustered raid could possible hang if
array received a METADATA_UPDATED msg after array unregistered
mddev->thread, so we need to stop clustered raid (bitmap_destroy
-> bitmap_free -> md_cluster_stop) earlier than unregister
thread (mddev_detach -> md_unregister_thread).
And this change should be safe for non-clustered raid since
all writes are stopped before the destroy. Also in md_run,
we activate the personality (pers->run()) before activating
the bitmap (bitmap_create()). So it is pleasingly symmetric
to stop the bitmap (bitmap_destroy()) before stopping the
personality (__md_stop() calls pers->free()), we achieve this
by move bitmap_destroy to the beginning of __md_stop.
But we don't want to break the codes for waiting behind IO as
Shaohua mentioned, so introduce bitmap_wait_behind_writes to
call the codes, and call the new fun in both mddev_detach and
bitmap_destroy, then we will not break original behind IO code
and also fit the new condition well.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Diffstat (limited to 'drivers/scsi/sr_ioctl.c')
0 files changed, 0 insertions, 0 deletions