On 13.09.19 12:15, Sergio Lopez wrote: > > Max Reitz <mre...@redhat.com> writes: > >> On 13.09.19 11:37, Sergio Lopez wrote: >>> >>> Max Reitz <mre...@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.
Hm. I suppose it depends. From the main context, it is OK to access all fields that only the main context accesses. So bdrv_try_set_aio_context() should be safe because they do that. I suppose the same goes for bdrv_op_is_blocked(), because op blockers are only set up or removed in the main context. So it should be safe as it is after all. Max
signature.asc
Description: OpenPGP digital signature
