From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36135) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZDdb-0000bo-0e for qemu-devel@nongnu.org; Wed, 01 Oct 2014 02:43:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZDdW-0002sq-ID for qemu-devel@nongnu.org; Wed, 01 Oct 2014 02:43:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZDdW-0002sm-9q for qemu-devel@nongnu.org; Wed, 01 Oct 2014 02:43:42 -0400 From: Markus Armbruster References: <1411744797-17121-1-git-send-email-boriss@gmail.com> <20140929214648.GA7692@irqsave.net> <20140930191748.GA14250@irqsave.net> Date: Wed, 01 Oct 2014 08:43:35 +0200 In-Reply-To: <20140930191748.GA14250@irqsave.net> (=?utf-8?Q?=22Beno=C3=AE?= =?utf-8?Q?t?= Canet"'s message of "Tue, 30 Sep 2014 21:17:48 +0200") Message-ID: <87sij8gui0.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2] Virtio-9p live migration patchset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?Q?Beno=C3=AEt?= Canet Cc: Boris Sukholitko , qemu-devel@nongnu.org Beno=C3=AEt Canet writes: > The Tuesday 30 Sep 2014 =C3=A0 22:08:12 (+0300), Boris Sukholitko wrote : >> On Tue, Sep 30, 2014 at 12:46 AM, Beno=C3=AEt Canet >> wrote: >> > The Friday 26 Sep 2014 =C3=A0 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 o= f 9p >> >> operations) as it wasn't working in my testing. >> > >> > It's probable that the second patch has bitrot but I remember I was as= ked to >> > write it for a meaningfull reason. >>=20 >> AFAICT, the reason was to drain requests queue before saving the state. >>=20 >> Unfortunately, releasing BQL haven't led to the callbacks being executed. >> Therefore deadlock ensued. >>=20 >> > Maybe you should give it a bit more love to resurect it properly. >> > >>=20 >> 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.