Hi,
在 2023/06/15 16:17, Xiao Ni 写道:
Thanks for the example. I can understand the usage of it. It's the
side effect that removes the mutex protection for idle_sync_thread.
There is a problem. New sync thread is started in md_check_recovery.
After your patch, md_reap_sync_thread is called in md_check_recovery
too. So it looks like they can't happen at the same time?
Of course they can't. md_check_recovery() can only do one thing at a
time.
After thinking a while, there is still a race possibility.
md_reap_sync_thread is called in pers deamon (e.g. raid10d ->
md_check_recovery) and md_check_recovery returns. Before
idle_sync_thread is woken, the new sync thread can be started in
md_check_recovery again.
But it's really strange, when one people echo idle to sync_action.
It's better to add some messages to notify the users that they need to
echo idle to sync_action again to have a try. Is there a way that
md_reap_sync_thread can wait idle_sync_thread?
I don't think this is a problem, echo idle only make sure to interupt
current sync_thread, there is no gurantee that sync_thread is not
running after "echo idle" is done with or without this patchset, before
this patchset, new sync thread can still start after the mutex is
released.
User shoud "echo forzen" instead of "echo idle" if they really what to
avoid new sync_thread to start.
Thanks,
Kuai
Regards
Xiao
Regards
Xiao
Thanks,
Kuai
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
