Il lun 26 set 2022, 14:21 Vladimir Sementsov-Ogievskiy <
vsement...@yandex-team.ru> ha scritto:
> On 9/18/22 20:12, Emanuele Giuseppe Esposito wrote:
> >>> --- a/qemu-img.c
> >>> +++ b/qemu-img.c
> >>> @@ -911,7 +911,6 @@ static void run_block_job(BlockJob *job, Error
> >>> **errp)
> >>>
On 9/18/22 20:12, Emanuele Giuseppe Esposito wrote:
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -911,7 +911,6 @@ static void run_block_job(BlockJob *job, Error
**errp)
AioContext *aio_context = block_job_get_aio_context(job);
int ret = 0;
- aio_context_acquire(aio_context);
On Thu, Sep 22, 2022 at 4:42 PM Emanuele Giuseppe Esposito
wrote:
>
> Am 18/09/2022 um 19:12 schrieb Emanuele Giuseppe Esposito:
> >> In replication_stop, we call job_cancel_sync() inside
> >> aio_context_acquire - aio_context_release section. Should it be fixed?
>
> > I don't think it breaks
Am 18/09/2022 um 19:12 schrieb Emanuele Giuseppe Esposito:
>> In replication_stop, we call job_cancel_sync() inside
>> aio_context_acquire - aio_context_release section. Should it be fixed?
> I don't think it breaks anything. The question is: what is the
> aiocontext there protecting? Do we need
Am 15/09/2022 um 16:52 schrieb Vladimir Sementsov-Ogievskiy:
> On 8/26/22 16:21, Emanuele Giuseppe Esposito wrote:
>> Change the job_{lock/unlock} and macros to use job_mutex.
>>
>> Now that they are not nop anymore, remove the aiocontext
>> to avoid deadlocks.
>>
>> Therefore:
>> - when
On 8/26/22 16:21, Emanuele Giuseppe Esposito wrote:
Change the job_{lock/unlock} and macros to use job_mutex.
Now that they are not nop anymore, remove the aiocontext
to avoid deadlocks.
Therefore:
- when possible, remove completely the aiocontext lock/unlock pair
- if it is used by some other
Change the job_{lock/unlock} and macros to use job_mutex.
Now that they are not nop anymore, remove the aiocontext
to avoid deadlocks.
Therefore:
- when possible, remove completely the aiocontext lock/unlock pair
- if it is used by some other function too, reduce the locking
section as much as
