qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [ANNOUNCE] QEMU 2.11.0-rc2 is now available


From: Jeff Cody
Subject: Re: [Qemu-devel] [ANNOUNCE] QEMU 2.11.0-rc2 is now available
Date: Wed, 22 Nov 2017 21:43:43 -0500
User-agent: Mutt/1.5.24 (2015-08-30)

On Thu, Nov 23, 2017 at 08:47:47AM +0800, Fam Zheng wrote:
> On Wed, 11/22 04:55, Jeff Cody wrote:
> > On Wed, Nov 22, 2017 at 09:09:02AM +0100, Christian Borntraeger wrote:
> > > 
> > > 
> > > On 11/22/2017 04:23 AM, Michael Roth wrote:
> > > > Quoting Christian Borntraeger (2017-11-21 15:38:32)
> > > >> forgot to cc qemu-devel....
> > > >>
> > > >> On 11/21/2017 10:37 PM, Christian Borntraeger wrote:
> > > >>> a quick heads up . Rc2 now triggers
> > > >>> +qemu-img: block/block-backend.c:2088: blk_root_drained_end: 
> > > >>> Assertion `blk->quiesce_counter' failed.
> > > >>> for several qemu iotests. 
> > > >>>
> > > >>> I have not looked into any details.
> > > > 
> > > > It looks to be due to:
> > > > 
> > > > 4afeffc8572f40d8844b946a30c00b10da4442b1
> > > > blockjob: do not allow coroutine double entry or entry-after-completion
> > > 
> > > Yes, I can confirm that reverting this patch gets rid of this assertion, 
> > > but
> > > I see things like
> > > 
> > > --- /home/cborntra/REPOS/qemu/tests/qemu-iotests/020.out  2017-11-21 
> > > 20:19:34.785519323 +0100
> > > +++ /home/cborntra/REPOS/qemu/build/tests/qemu-iotests/020.out.bad        
> > > 2017-11-22 09:04:50.127612500 +0100
> > > @@ -537,7 +537,8 @@
> > >  wrote 65536/65536 bytes at offset 4295098368
> > >  64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > >  No errors were found on the image.
> > > -Image committed.
> > > +qemu_aio_coroutine_enter: Co-routine was already scheduled in 
> > > 'co_aio_sleep_ns'
> > > +./common.rc: line 61: 88002 Aborted                 (core dumped) ( exec 
> > > "$QEMU_IMG_PROG" $QEMU_IMG_OPTIONS "$@" )
> > > 
> > 
> > That is from the subsequent patches in the series - you will want to revert
> > the whole series to test, as the introduced aborts catch the illegal
> > entries that the reverted patch sidestepped.
> > 
> > The series patches are:
> > 
> > 4afeffc
> > 6133b39
> > a233969
> > d975301
> > 
> > Of course, these new aborts prevent improper behavior, so we may want to
> > figure out why this is getting hit.
> > 
> > Unfortunately, I am traveling at the moment (waiting to board my flight), so
> > will have limited connectivity.
> 
> I'll take a look at this today and the bottom line is we revert the series 
> until
> a proper fix is found.
> 

My hunch is the series is a proper fix, but uncovered other latent bugs that
were relying on dangerous behavior.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]