All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emanuele Giuseppe Esposito <eesposit@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Max Reitz <mreitz@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, John Snow <jsnow@redhat.com>
Subject: Re: [PATCH 5/6] co-shared-resource: protect with a mutex
Date: Fri, 14 May 2021 16:32:02 +0200	[thread overview]
Message-ID: <8008b39d-905c-3858-a96f-8609801a4ae0@redhat.com> (raw)
In-Reply-To: <6b9d7c37-aaf7-1745-260b-4cce8f0891ee@virtuozzo.com>



On 14/05/2021 16:26, Vladimir Sementsov-Ogievskiy wrote:
> 14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
>>
>>
>> On 12/05/2021 17:44, Stefan Hajnoczi wrote:
>>> On Mon, May 10, 2021 at 10:59:40AM +0200, Emanuele Giuseppe Esposito 
>>> wrote:
>>>> co-shared-resource is currently not thread-safe, as also reported
>>>> in co-shared-resource.h. Add a QemuMutex because co_try_get_from_shres
>>>> can also be invoked from non-coroutine context.
>>>>
>>>> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
>>>> ---
>>>>   util/qemu-co-shared-resource.c | 26 ++++++++++++++++++++++----
>>>>   1 file changed, 22 insertions(+), 4 deletions(-)
>>>
>>> Hmm...this thread-safety change is more fine-grained than I was
>>> expecting. If we follow this strategy basically any data structure used
>>> by coroutines needs its own fine-grained lock (like Java's Object base
>>> class which has its own lock).
>>>
>>> I'm not sure I like it since callers may still need coarser grained
>>> locks to protect their own state or synchronize access to multiple
>>> items of data. Also, some callers may not need thread-safety.
>>>
>>> Can the caller to be responsible for locking instead (e.g. using
>>> CoMutex)?
>>
>> Right now co-shared-resource is being used only by block-copy, so I 
>> guess locking it from the caller or within the API won't really matter 
>> in this case.
>>
>> One possible idea on how to delegate this to the caller without adding 
>> additional small lock/unlock in block-copy is to move 
>> co_get_from_shres in block_copy_task_end, and calling it only when a 
>> boolean passed to block_copy_task_end is true.
>>
>> Otherwise make b_c_task_end always call co_get_from_shres and then 
>> include co_get_from_shres in block_copy_task_create, so that we always 
>> add and in case remove (if error) in the shared resource.
>>
>> Something like:
>>
>> diff --git a/block/block-copy.c b/block/block-copy.c
>> index 3a447a7c3d..1e4914b0cb 100644
>> --- a/block/block-copy.c
>> +++ b/block/block-copy.c
>> @@ -233,6 +233,7 @@ static coroutine_fn BlockCopyTask 
>> *block_copy_task_create(BlockCopyState *s,
>>       /* region is dirty, so no existent tasks possible in it */
>>       assert(!find_conflicting_task(s, offset, bytes));
>>       QLIST_INSERT_HEAD(&s->tasks, task, list);
>> +    co_get_from_shres(s->mem, task->bytes);
>>       qemu_co_mutex_unlock(&s->tasks_lock);
>>
>>       return task;
>> @@ -269,6 +270,7 @@ static void coroutine_fn 
>> block_copy_task_end(BlockCopyTask *task, int ret)
>>           bdrv_set_dirty_bitmap(task->s->copy_bitmap, task->offset, 
>> task->bytes);
>>       }
>>       qemu_co_mutex_lock(&task->s->tasks_lock);
>> +    co_put_to_shres(task->s->mem, task->bytes);
>>       task->s->in_flight_bytes -= task->bytes;
>>       QLIST_REMOVE(task, list);
>>       progress_set_remaining(task->s->progress,
>> @@ -379,7 +381,6 @@ static coroutine_fn int 
>> block_copy_task_run(AioTaskPool *pool,
>>
>>       aio_task_pool_wait_slot(pool);
>>       if (aio_task_pool_status(pool) < 0) {
>> -        co_put_to_shres(task->s->mem, task->bytes);
>>           block_copy_task_end(task, -ECANCELED);
>>           g_free(task);
>>           return -ECANCELED;
>> @@ -498,7 +499,6 @@ static coroutine_fn int 
>> block_copy_task_entry(AioTask *task)
>>       }
>>       qemu_mutex_unlock(&t->s->calls_lock);
>>
>> -    co_put_to_shres(t->s->mem, t->bytes);
>>       block_copy_task_end(t, ret);
>>
>>       return ret;
>> @@ -687,8 +687,6 @@ block_copy_dirty_clusters(BlockCopyCallState 
>> *call_state)
>>
>>           trace_block_copy_process(s, task->offset);
>>
>> -        co_get_from_shres(s->mem, task->bytes);
> 
> we want to get from shres here, after possible call to 
> block_copy_task_shrink(), as task->bytes may be reduced.

Ah right, I missed that. So I guess if we want the caller to protect 
co-shared-resource, get_from_shres stays where it is, and put_ instead 
can still go into task_end (with a boolean enabling it).

Thank you
Emanuele
> 
>> -
>>           offset = task_end(task);
>>           bytes = end - offset;
>>
>>
>>
>>
>>>
>>>> diff --git a/util/qemu-co-shared-resource.c 
>>>> b/util/qemu-co-shared-resource.c
>>>> index 1c83cd9d29..c455d02a1e 100644
>>>> --- a/util/qemu-co-shared-resource.c
>>>> +++ b/util/qemu-co-shared-resource.c
>>>> @@ -32,6 +32,7 @@ struct SharedResource {
>>>>       uint64_t available;
>>>>       CoQueue queue;
>>>> +    QemuMutex lock;
>>>
>>> Please add a comment indicating what this lock protects.
>>>
>>> Thread safety should also be documented in the header file so API users
>>> know what to expect.
>>
>> Will do, thanks.
>>
>> Emanuele
>>
> 
> 



  reply	other threads:[~2021-05-14 14:33 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-10  8:59 [PATCH 0/6] block-copy: make helper APIs thread safe Emanuele Giuseppe Esposito
2021-05-10  8:59 ` [PATCH 1/6] ratelimit: treat zero speed as unlimited Emanuele Giuseppe Esposito
2021-05-10 11:00   ` Vladimir Sementsov-Ogievskiy
2021-05-10  8:59 ` [PATCH 2/6] block-copy: let ratelimit handle a speed of 0 Emanuele Giuseppe Esposito
2021-05-10 11:06   ` Vladimir Sementsov-Ogievskiy
2021-05-10  8:59 ` [PATCH 3/6] blockjob: " Emanuele Giuseppe Esposito
2021-05-10 11:17   ` Vladimir Sementsov-Ogievskiy
2021-05-10  8:59 ` [PATCH 4/6] progressmeter: protect with a mutex Emanuele Giuseppe Esposito
2021-05-10 11:28   ` Vladimir Sementsov-Ogievskiy
2021-05-10 16:52     ` Emanuele Giuseppe Esposito
2021-05-10 17:17       ` Vladimir Sementsov-Ogievskiy
2021-05-10 17:57         ` Emanuele Giuseppe Esposito
2021-05-11 12:28     ` Paolo Bonzini
2021-05-12  7:09       ` Vladimir Sementsov-Ogievskiy
2021-05-12 15:53   ` Stefan Hajnoczi
2021-05-10  8:59 ` [PATCH 5/6] co-shared-resource: " Emanuele Giuseppe Esposito
2021-05-10 11:40   ` Vladimir Sementsov-Ogievskiy
2021-05-11  8:34     ` Paolo Bonzini
2021-05-12 15:44   ` Stefan Hajnoczi
2021-05-12 18:30     ` Paolo Bonzini
2021-05-14 14:10     ` Emanuele Giuseppe Esposito
2021-05-14 14:26       ` Vladimir Sementsov-Ogievskiy via
2021-05-14 14:32         ` Emanuele Giuseppe Esposito [this message]
2021-05-14 15:30           ` Vladimir Sementsov-Ogievskiy via
2021-05-14 17:28             ` Emanuele Giuseppe Esposito
2021-05-14 21:15               ` Vladimir Sementsov-Ogievskiy via
2021-05-14 21:53                 ` Emanuele Giuseppe Esposito
2021-05-15  7:11                   ` Vladimir Sementsov-Ogievskiy via
2021-05-14 17:55       ` Paolo Bonzini
2021-05-10  8:59 ` [PATCH 6/6] aiopool: " Emanuele Giuseppe Esposito
2021-05-10 11:56   ` Vladimir Sementsov-Ogievskiy
2021-05-11  8:34     ` Paolo Bonzini
2021-05-12 15:19   ` Stefan Hajnoczi
2021-05-10 10:55 ` [PATCH 0/6] block-copy: make helper APIs thread safe Vladimir Sementsov-Ogievskiy
2021-05-12 14:24 ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8008b39d-905c-3858-a96f-8609801a4ae0@redhat.com \
    --to=eesposit@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.