On 2/14/19 10:46 AM, Eric Blake wrote:
> On 2/13/19 5:49 PM, John Snow wrote:
>> When bitmaps are persistent, they may incur a disk read or write when bitmaps
>> are added or removed. For configurations like virtio-dataplane, failing to
>> acquire this lock will abort QEMU when disk IO occurs.
>>
>> We used to acquire aio_context as part of the bitmap lookup, so re-introduce
>> the lock for just the cases that have an IO penalty. Commit 2119882c removed
>> these locks, and I failed to notice this when we committed fd5ae4cc, so this
>> has been broken since persistent bitmaps were introduced.
>>
>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1672010
>> Reported-By: Aihua Liang <ali...@redhat.com>
>> Signed-off-by: John Snow <js...@redhat.com>
>> Reviewed-by: Eric Blake <ebl...@redhat.com>
>> Message-id: 20190213195501.7790-2-js...@redhat.com
>> Signed-off-by: John Snow <js...@redhat.com>
>> ---
>> blockdev.c | 26 ++++++++++++++++++++------
>> 1 file changed, 20 insertions(+), 6 deletions(-)
>
>> bitmap = bdrv_create_dirty_bitmap(bs, granularity, name, errp);
>> if (bitmap == NULL) {
>> - return;
>> + goto out
>
> Embarrassing enough that I missed this syntax error in spite of my R-b,
> but even more embarrassing that we have a pull request that has
> obviously not been compiled. At least patchew called it out.
Hm, yes, I swore I *did* compile and test this, but it clearly must have
been on the outdated patch.
>
> We're not in enough of a rush to need this PR to land this week, so I
> won't try to post a v2 on your behalf, but will instead wait for your
> return next week.
>
Was trying to stay ahead of my long weekend instead of carrying these
patches forever. Please forgive the error.
--js
