diff options
author | Guoqing Jiang <gqjiang@suse.com> | 2017-03-14 09:40:20 +0800 |
---|---|---|
committer | Shaohua Li <shli@fb.com> | 2017-03-16 16:55:58 -0700 |
commit | 48df498daf62e1292868005675331929305067f0 (patch) | |
tree | fa449f9bdc074689955e4c6d8f5d62087b619c77 /drivers/i2c/Makefile | |
parent | ea17481fb48888fa11f412766bde36be9171247e (diff) |
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/i2c/Makefile')
0 files changed, 0 insertions, 0 deletions