On Thu, Jun 15, 2023 at 5:05 PM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote: > > 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 for all the explanations and patience. Regards Xiao > > 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
