[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] block: don't set the same context

From: Denis Plotnikov
Subject: Re: [Qemu-devel] [PATCH] block: don't set the same context
Date: Fri, 15 Feb 2019 13:01:14 +0000

On 15.02.2019 15:29, Eric Blake wrote:
> On 2/15/19 3:19 AM, Denis Plotnikov wrote:
>> Adds a fast path on aio context setting preventing
>> unnecessary context setting routine.
>> Also, it prevents issues with cyclic walk of child
>> bds-es appeared because of registring aio walking
> registering
will fix it
>> notifiers:
>> This can happen because of "new" context attachment to VM disk bds.
>> When attaching a new context the corresponding aio context handler is
>> called for each of aio_notifiers registered on the VM disk bds context.
>> Among those handlers, there is the block_job_attached_aio_context handler
>> which sets a new aio context for the block job bds. When doing so,
>> the old context is detached from all the block job bds children and one of
>> them is the VM disk bds, serving as backing store for the blockjob bds,
>> although the VM disk bds is actually the initializer of that process.
>> Since the VM disk bds is protected with walking_aio_notifiers flag
>> from double processing in recursive calls, the assert fires.
>> Signed-off-by: Denis Plotnikov <address@hidden>
>> ---
>>   block.c | 4 ++++
>>   1 file changed, 4 insertions(+)
> Naive question - do we have to always call
> attach_aio_context/detach_aio_context in pairs?
seems, to be so. the only user doing attach/detach is bdrv_set_aio_context
   If so, will
> short-circuiting a nested attach cause reference count problems when we
> come to the matching detach calls?
I don't quite understand. I suggested the short circuit for 
bdrv_set_aio_context which actually pairs attach/detach context. So, the 
pairing here should be a problem


reply via email to

[Prev in Thread] Current Thread [Next in Thread]