From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boqbM-0007HO-Nf for qemu-devel@nongnu.org; Tue, 27 Sep 2016 07:31:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1boqbG-0000i9-Vh for qemu-devel@nongnu.org; Tue, 27 Sep 2016 07:31:07 -0400 Received: from mx01.kamp.de ([82.141.2.16]:44174) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boqbG-0000hR-KW for qemu-devel@nongnu.org; Tue, 27 Sep 2016 07:31:02 -0400 References: <20160817193046.7220.688@loki> <8e3ac487-a3ee-1aef-2240-4c388e0004f7@kamp.de> <20160825172345.17599.42638@loki> <38b365e3-4182-d9d9-28d6-275dfad0da8a@kamp.de> <20160905175435.GF24387@stefanha-x1.localdomain> <20160908205826.17599.75522@loki> <20160913154248.GC5677@stefanha-x1.localdomain> <51785872-1D0C-419D-B03E-34A63F81C6BD@kamp.de> <20160913180459.17438.49499@loki> <92840511-4c81-f845-0512-788abf6fe08e@kamp.de> <838b4d20-496e-2b48-125b-41d82c415b6e@kamp.de> From: Peter Lieven Message-ID: Date: Tue, 27 Sep 2016 13:30:27 +0200 MIME-Version: 1.0 In-Reply-To: <838b4d20-496e-2b48-125b-41d82c415b6e@kamp.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-stable] [ANNOUNCE] QEMU 2.6.1 Stable released List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth , Stefan Hajnoczi Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-stable@nongnu.org, Gerd Hoffmann , "Daniel P. Berrange" , arei.gonglei@huawei.com Am 27.09.2016 um 12:28 schrieb Peter Lieven: > Am 16.09.2016 um 15:56 schrieb Peter Lieven: >> Am 13.09.2016 um 20:04 schrieb Michael Roth: >>> Quoting Peter Lieven (2016-09-13 10:52:04) >>>>> Am 13.09.2016 um 17:42 schrieb Stefan Hajnoczi: >>>>> >>>>>> On Thu, Sep 08, 2016 at 03:58:26PM -0500, Michael Roth wrote: >>>>>> Quoting Stefan Hajnoczi (2016-09-05 12:54:35) >>>>>>>> On Fri, Aug 26, 2016 at 01:45:56PM +0200, Peter Lieven wrote: >>>>>>>>> Am 25.08.2016 um 19:23 schrieb Michael Roth: >>>>>>>>> Quoting Peter Lieven (2016-08-25 01:38:13) >>>>>>>>>> 7c509d1 virtio: decrement vq->inuse in virtqueue_discard() >>>>>>>>>> 700f26b virtio: recalculate vq->inuse after migration >>>>>>>>> Looks like these got posted during the freeze :( >>>>>>>>> >>>>>>>>>> The virtio thing is important because live migration is broken without >>>>>>>>>> the fix as 86cc089 is in 2.6.1. >>>>>>>>> Not sure I understand the relation to 86cc089. Wouldn't the check >>>>>>>>> introduced there always pass due to target initializing inuse to 0? >>>>>>>>> >>>>>>>>> Or is the issue that the fix introduced in 86cc089 is only partially >>>>>>>>> effective due to inuse not being recalculated properly on target? That might >>>>>>>>> warrant a 2.6.1.1... >>>>>>>> This is what Stefan wrote in the cover letter to the series: >>>>>>>> >>>>>>>> "I should mention this is for QEMU 2.7. These fixes are needed if the >>>>>>>> CVE-2016-5403 patch has been applied. Without these patches any device that holds VirtQueueElements acros >>>>>>>> live migration will terminate with a "Virtqueue size exceeded" error message. virtio-balloon and virtio-scsi are affected. virtio-bl >>>>>>>> probably too but I haven't tested it." >>>>>>>> >>>>>>>> Maybe >>>>>>> The virtio inuse fixes are needed for stable (v2.6.2?) so that the >>>>>>> spurious "Virtqueue size exceeded" on migration is solved. >>>>>>> >>>>>>> The error can be reproduced when there is a VirtQueueElement pending >>>>>>> across migration (e.g. virtio-blk s->rq failed request list). >>>>>> Thanks for clarifying. I'm planning to do a 2.6.2 to capture these, the >>>>>> patches Peter mentioned, and some other fixes that came during 2.7 RC >>>>>> phase. >>>>>> >>>>>> I have an initial staging tree at: >>>>>> >>>>>> https://github.com/mdroth/qemu/commits/stable-2.6-staging >>>>>> >>>>>> There's still a few PULLs in flight with patches I plan to pull in, but >>>>>> hoping to send out the patch round-up early next week and a release the >>>>>> following week. >>>>> Two more candidates for stable: >>>>> >>>>> 4b7f91e virtio: zero vq->inuse in virtio_reset() >>>>> 104e70c virtio-balloon: discard virtqueue element on reset >>>>> >>>>> They also deal with "Virtqueue size exceeded" errors. >>>>> >>>>> Stefan >>>> There also seems to be an regression (segfault) in the VNC server in 2.6.1, but i am still investigating. >>> Do you have a reproducer? I can try a bisect. Trying to get the initial >>> staging tree posted today but want to make sure any known regressions are >>> addressed beforehand. >> >> Hi Michael, >> >> we have not been able to reproduce anymore. My guess is that our client had a bug in the new version >> and that the regression can only happen in a special connection state. But we are still trying >> to reproduce. > > We are again able to reproduce the VNC error. The vServer dies with: > > qemu: qemu_mutex_lock: Invalid argument > > We are working on it. The bug we faced is fixed upstream in: ui: avoid crash if vnc client disconnects with writes pending This should definetly go in 2.6.2 Other vnc related patches might also go in: vnc: make sure we finish disconnect vnc: ensure connection sharing/limits is always configured vnc: fix crash when vnc_server_info_get has an error vnc: don't crash getting server info if lsock is NULL vnc-enc-tight: fix off-by-one bug vnc: fix incorrect checking condition when updating client unfortunately none of these had qemu-stable in CC. Peter