qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/9] blockdev: fix QMP 'transaction' with IOT


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v2 0/9] blockdev: fix QMP 'transaction' with IOThreads
Date: Fri, 8 Dec 2017 14:29:36 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

Am 06.12.2017 um 15:45 hat Stefan Hajnoczi geschrieben:
> v2:
>  * Use StrOrNull for x-blockdev-set-iothread iothread argument [eblake]
> 
> (This is for QEMU 2.12 because this bug is not -rc4 critical)
> 
> Previously AioContext was held across QMP 'transaction' in an attempt to
> achieve bdrv_drained_begin/end() semantics.  Nowadays we have
> bdrv_drained_begin/end() and the AioContext lock just protects state.
> Therefore there is no reason to hold AioContext across
> .prepare/.commit/.abort/.clean() anymore.
> 
> Besides being cleanup-worthy, holding AioContext also exposes a bug:
> BDRV_POLL_WHILE() doesn't support recursive AioContext locking and will hang 
> if
> depth > 1.  This is easy to trigger by submitting a transaction with 2 actions
> that touch two drives assigned to an IOThread.  The IOThread's AioContext will
> be locked twice and BDRV_POLL_WHILE() will hang.
> 
> BDRV_POLL_WHILE() is best fixed by eliminating the AioContext lock entirely in
> favor of fine-grained locking.  I discussed some fixes for BDRV_POLL_WHILE()
> with Paolo but we came to the conclusion that it will just add complexity when
> we really want to stop using AioContext locking.

Reviewed-by: Kevin Wolf <address@hidden>

The only thing that I see that could use some improvements is the test
case, which tests only a small part of the bugs that are fixed by this
series. This doesn't invalidate any of the review, but I think without
full test coverage, it's incomplete.

Kevin



reply via email to

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