Re: [PATCH v5 0/5] block-copy: protect block-copy internal structures

[Vladimir Sementsov-Ogievskiy]

24.06.2021 10:20, Emanuele Giuseppe Esposito wrote:
> This serie of patches aims to reduce the usage of the
> AioContexlock in block-copy, by introducing smaller granularity
> locks thus on making the block layer thread safe.
>
> This serie depends on my previous serie that brings thread safety
> to the smaller API used by block-copy, like ratelimit, progressmeter
> abd co-shared-resource.
>
> What's missing for block-copy to be fully thread-safe is fixing
> the CoSleep API to allow cross-thread sleep and wakeup.
> Paolo is working on it.
>
> Patch 1 provides a small refactoring, patch 2 introduces the
> .method field in BlockCopyState, to be used instead of .use_copy_range,
> .copy_size and .zeros.
> Patch 3 provide a refactoring in preparation to
> the lock added in patch 4 on BlockCopyTask, BlockCopyCallState and
> BlockCopyState. Patch 5 uses load_acquire/store_release to make sure
> BlockCopyCallState OUT fields are updated before finished is set to
> true.
>
> Based-on: <20210518094058.25952-1-eesposit@redhat.com>
> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
> ---
> v5:
> * Squash patch 3 (improve comments) with patch 5 (add CoMutex).
> * Better comments in block-copy, drop IN/OUT/State categories
> * Remove some load_acquire in patch 6, replace them with atomic reads
>
>
> Emanuele Giuseppe Esposito (4):
>    block-copy: small refactor in block_copy_task_entry and
>      block_copy_common
>    block-copy: move progress_set_remaining in block_copy_task_end
>    block-copy: add CoMutex lock
>    block-copy: atomic .cancelled and .finished fields in
>      BlockCopyCallState
>
> Paolo Bonzini (1):
>    block-copy: streamline choice of copy_range vs. read/write
>
>   include/block/block-copy.h |   2 +
>   block/block-copy.c         | 368 +++++++++++++++++++++++--------------
>   2 files changed, 231 insertions(+), 139 deletions(-)


Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>


--
Best regards,
Vladimir