From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an0B9-0000MQ-3Z for qemu-devel@nongnu.org; Mon, 04 Apr 2016 04:48:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1an0B4-0007fD-HC for qemu-devel@nongnu.org; Mon, 04 Apr 2016 04:48:11 -0400 Date: Mon, 4 Apr 2016 11:47:58 +0300 From: "Michael S. Tsirkin" Message-ID: <20160404114449-mutt-send-email-mst@redhat.com> References: <1459679740-17519-1-git-send-email-mst@redhat.com> <57017629.9090108@de.ibm.com> <57018778.8060408@redhat.com> <20160404101013.4dec0db2.cornelia.huck@de.ibm.com> <5702239E.5070407@redhat.com> <20160404102534.4ff786f2.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160404102534.4ff786f2.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] [PATCH] virtio-blk: assert on starting/stopping List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Kevin Wolf , qemu-block@nongnu.org, qemu-devel@nongnu.org, Christian Borntraeger , Stefan Hajnoczi , Paolo Bonzini On Mon, Apr 04, 2016 at 10:25:34AM +0200, Cornelia Huck wrote: > On Mon, 4 Apr 2016 10:19:42 +0200 > Paolo Bonzini wrote: > > > On 04/04/2016 10:10, Cornelia Huck wrote: > > > > This will be fixed by Cornelia's rework, and is an example of why I > > > > think patch 1/9 is a good idea (IOW, assign=false is harmful). > > > > > > So what do we want to do for 2.6? The aio handler rework (without the > > > cleanup) is needed. Do we want to include the minimal version of my > > > "keep handler assigned" patch (the one without the api rework) as well, > > > as it fixes a latent bug? > > > > I would, but Michael is more conservative in general. Since the > > difference between a bug and a feature is very fuzzy here, I would just > > omit my patch 9. > > I'd omit patch 9 as well, but the knowledge that the "handler > deassigned" bug is still lurking makes me uncomfortable. It's not a bug as such - that logic was relying on handler invoking itself being a nop and that assumption broke with dataplane rework. > Would like to see a test from someone with a large setup, anyway (and I > need to enhance my test setup, I guess...) Now that Christian sent the backtrace I feel with understand the issues, but more testing is always good :) -- MST