[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 0/3] block-copy: lock tasks and calls list
From: |
Vladimir Sementsov-Ogievskiy |
Subject: |
Re: [RFC PATCH 0/3] block-copy: lock tasks and calls list |
Date: |
Tue, 20 Apr 2021 16:12:05 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 |
20.04.2021 13:04, Emanuele Giuseppe Esposito wrote:
This serie of patches continues Paolo's series on making the
block layer thread safe. Add a CoMutex lock for both tasks and
calls list present in block/block-copy.c
I think, we need more information about what kind of thread-safety we want.
Should the whole interface of block-copy be thread safe? Or only part of it?
What is going to be shared between different threads? Which functions will be
called concurrently from different threads? This should be documented in
include/block/block-copy.h.
What I see here, is that some things are protected by mutex.. Some things not.
What became thread-safe?
For example, in block_copy_dirty_clusters(), we modify task fields without any
mutex held:
block_copy_task_shrink doesn't take mutex.
task->zeroes is set without mutex as well
Still all these accesses are done when task is already added to the list.
Looping in block_copy_common() is not thread safe as well.
You also forget to protect QLIST_REMOVE() call in block_copy_task_end()..
Next, block-copy uses co-shared-resource API, which is not thread-safe (as it
is directly noted in include/qemu/co-shared-resource.h).
Same thing is block/aio_task API, which is not thread-safe too.
So, we should bring thread-safety first to these smaller helper APIs.
--
Best regards,
Vladimir