Re: [Qemu-devel] [PATCH] blockdev: avoid acquiring AioContext lock twice at do_drive_backup()

[Sergio Lopez <slp@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]


Max Reitz <mreitz@redhat.com> writes:

> On 13.09.19 11:37, Sergio Lopez wrote:
>> 
>> Max Reitz <mreitz@redhat.com> writes:
>> 
>>> On 12.09.19 18:16, Sergio Lopez wrote:
>>>> do_drive_backup() acquires the AioContext lock of the corresponding
>>>> BlockDriverState. This is not a problem when it's called from
>>>> qmp_drive_backup(), but drive_backup_prepare() also acquires the lock
>>>> before calling it.
>>>>
>>>> This change adds a BlockDriverState argument to do_drive_backup(),
>>>> which is used to signal that the context lock is already acquired and
>>>> to save a couple of redundant calls.
>>>
>>> But those redundant calls don’t really hurt (it’s just bdrv_lookup_bs(),
>>> as far as I can tell).  Wouldn’t it be simpler to just release the
>>> context lock in drive_backup_prepare() before calling do_drive_backup()?
>>>  The BDS is drained anyway.
>> 
>> Redundant calls rarely hurt, they're just redundant ;-)
>
> If they’re expensive and in a hot path, they hurt.
>
>>> On top of that, do_backup_common() calls bdrv_try_set_aio_context() to
>>> bring the target into the source’s AioContext.  However, this function
>>> must be called with the old AioContext held, and the new context not held.
>> 
>> Is this documented somewhere? I see nothing in the function declaration
>> nor definition.
>> 
>> I'm starting to get the feeling that the block layer is riddled with
>> unwritten rules and assumptions that makes every change a lot harder
>> than it should be.
>
> It is written, it’s just that it’s written in
> bdrv_set_aio_context_ignore()’s definition.
>
> Yes, we should document it directly for bdrv_try_set_aio_context(), too,
> because that’s what external callers are much more likely to use.
>
>>> Currently, it’s called exactly the other way around: With the new
>>> context held, but the old one not held.
>>>
>>> So I think it indeed actually makes more sense to release the AioContext
>>> before calling do_drive_backup(), and to move the
>>> bdrv_try_set_aio_context() call for target_bs to the callers of
>>> do_backup_common() (where they have not yet taken the AioContext lock).
>> 
>> OK. I see this also happens in external_snapshot_prepare() and
>> qmp_drive_mirror() too. I guess we should fix these too.
>> 
>> In qmp_drive_mirror(), would it be safe to delay the acquisition of any
>> context until just before the blockdev_mirror_common()?
>
> From mirror’s perspective I think so, but I don’t think it’s safe to
> access any of a BDS’s fields without having acquired its AioContext.
> (In fact, I wonder whether we should acquire the context even before
> bdrv_op_is_blocked()...)

In that case, I wonder if we can safely release the context to honor
bdrv_try_set_aio_context() requirements, knowing we aren't in a drained
section.

Sergio.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]