From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40715)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ao7wW-0007Yn-D1
	for qemu-devel@nongnu.org; Thu, 07 Apr 2016 07:17:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ao7wT-0002nB-6K
	for qemu-devel@nongnu.org; Thu, 07 Apr 2016 07:17:44 -0400
Received: from mx1.redhat.com ([209.132.183.28]:55890)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ao7wT-0002n7-0U
	for qemu-devel@nongnu.org; Thu, 07 Apr 2016 07:17:41 -0400
References: <57063EA4.6050402@cn.fujitsu.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <570641CF.7000704@redhat.com>
Date: Thu, 7 Apr 2016 13:17:35 +0200
MIME-Version: 1.0
In-Reply-To: <57063EA4.6050402@cn.fujitsu.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Questions about nbd with QIOChannel
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Changlong Xie <xiecl.fnst@cn.fujitsu.com>, qemu devel <qemu-devel@nongnu.org>, "Daniel P. Berrange" <berrange@redhat.com>
Cc: Li Zhijian <lizhijian@cn.fujitsu.com>, zhanghailiang <zhang.zhanghailiang@huawei.com>



On 07/04/2016 13:04, Changlong Xie wrote:
> Hi all
> 
> Recently during test COLO, i found sometimes the client goes to hung on
> Primary side. First i thought it maybe a COLO revelant issue, but after
> ton of tests i doubt that this maybe a NBD issue (athough i'm not sure).
> So i'd like to share what i found:
> 
> Since commit 1c778ef7, we convert to using QIOChannel APIs for actual
> socket I/O.
> 
> nbd_reply_ready()
>   read_sync()
>     nbd_wr_syncv()
>     {
>      ...
>      while (nlocal_iov > 0) {
>          ...
>          if (do_read) {
>              len = qio_channel_readv(ioc, local_iov, nlocal_iov,
>                                      &local_err);
>          } else {
>              ...
>          }
>          if (len == QIO_CHANNEL_ERR_BLOCK) {
>              if (qemu_in_coroutine()) {
>                  qemu_coroutine_yield();
>              } else {
>                  qio_channel_wait(ioc,
>                                   do_read ? G_IO_IN : G_IO_OUT);
>              }

You are right; you've found a bug.

Paolo