Re: [PATCHv4] qemu: allow blkstat/blkinfo calls during migration

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

 



On 05/21/2011 01:21 AM, Paolo Bonzini wrote:
> On 05/21/2011 12:11 AM, Eric Blake wrote:
>> I think we're safe.  It shouldn't matter if thread 2 reads thread 3's
>> answer (because they are both read-only queries, and should be getting
>> the same answer; or even if the answers differ, reading the newer answer
>> is not horrible because it is still an accurate answer).
> 
> The queries could be for different disks, and one might fail.  The
> problem is mostly if the first fails and the second succeeds, and the
> program sees a success instead of a failure.
> 
> ... but a much simpler fix is to make statRetCode a pointer, so that
> there is nothing to do on the producer side after the flag has been
> reset.  I strongly suggest doing this, as it is a very simple change
> that Cannot Make Things Worse (TM).

Ah, that does make sense.  Instead of storing the answers directly in
the memory shared between query and migration loop, the shared memory
should instead store pointers to stack-local memory in the query code.
Thus, the migration loop writes back to unique memory, and the moment it
clears the condition flag, it doesn't matter if some other thread starts
overwriting the pointers, because the first caller now knows that its
answers are safe.

Federico, do you want to tackle this, or shall I?

-- 
Eric Blake   eblake@xxxxxxxxxx    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]