Re: [Qemu-devel] [PATCH 0/2] Virtio-9p live migration patchset

[Markus Armbruster <armbru@redhat.com>]

Benoît Canet <benoit.canet@irqsave.net> writes:

> The Tuesday 30 Sep 2014 à 22:08:12 (+0300), Boris Sukholitko wrote :
>> On Tue, Sep 30, 2014 at 12:46 AM, Benoît Canet
>> <benoit.canet@irqsave.net> wrote:
>> > The Friday 26 Sep 2014 à 18:19:55 (+0300), Boris Sukholitko wrote :
>> >> This patchset is a small rebase of the 9p live migration patches
>> >> made a year
>> >> ago by Benoit Canet.
>> >>
>> >> See http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg02190.html
>> >> for the previous thread.
>> >>
>> >> I took the liberty to drop the second patch (waiting for completion of 9p
>> >> operations) as it wasn't working in my testing.
>> >
>> > It's probable that the second patch has bitrot but I remember I was asked to
>> > write it for a meaningfull reason.
>> 
>> AFAICT, the reason was to drain requests queue before saving the state.
>> 
>> Unfortunately, releasing BQL haven't led to the callbacks being executed.
>> Therefore deadlock ensued.
>> 
>> > Maybe you should give it a bit more love to resurect it properly.
>> >
>> 
>> I probably should. Still, IMHO, the two patches work good enough
>> to deserve merging on their own right :)
>
> I am afraid nobody will want to merge a patchset where there is a
> theorical potential bug.
>
> It should work as well on paper as on silicon.

Imperfect or incomplete patches *may* be acceptable when

A. they strictly improve things, and

B. their shortcomings are written down.

Example of a strict improvement: before the patch, live migration always
fails.  After the patch, it succeeds most of the time, but can still
fail in certain states.

Counter-example: before the patch, live migration always fails.  After
the patch, it succeeds, but can corrupt data in certain states.