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 <[email protected]> >> --- >> 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 >
-- Best, Denis
