From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34860)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1YIZgb-0007hf-Cw
	for qemu-devel@nongnu.org; Tue, 03 Feb 2015 04:22:22 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1YIZgX-0008Lz-CG
	for qemu-devel@nongnu.org; Tue, 03 Feb 2015 04:22:21 -0500
Received: from mx1.redhat.com ([209.132.183.28]:37300)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1YIZgX-0008KY-4U
	for qemu-devel@nongnu.org; Tue, 03 Feb 2015 04:22:17 -0500
Date: Tue, 3 Feb 2015 10:22:10 +0100
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20150203092153.GA4488@noname.redhat.com>
References: <54CB3BB4.80406@cn.fujitsu.com>
	<20150130133955.GB24537@noname.redhat.com>
	<54CED08C.2080501@cn.fujitsu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54CED08C.2080501@cn.fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH] quorum: don't share qiov
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: Wen Congyang <wency@cn.fujitsu.com>
Cc: pbonzini@redhat.com, qemu-devl <qemu-devel@nongnu.org>, Stefan Hajnoczi <stefanha@redhat.com>

Am 02.02.2015 um 02:19 hat Wen Congyang geschrieben:
> On 01/30/2015 09:39 PM, Kevin Wolf wrote:
> > Am 30.01.2015 um 09:07 hat Wen Congyang geschrieben:
> >> If the child touches qiov->iov, it will cause unexpected results.
> >>
> >> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > 
> > Any specific child you're thinking of?
> > 
> > I think children are not supposed to modify their qiov (which would also
> > fail for init_external qiovs). Perhaps we should have made it const.
> 
> NBD client. The qiov will be modified in iov_send_recv():
> nbd_co_writev()
>     nbd_client_session_co_writev()
>         nbd_co_writev_1()
>             nbd_co_send_request()
>                 qemu_co_sendv()
>                     qemu_co_sendv_recvv()
>                         iov_send_recv()

Paolo, I think it's rather surprising that iov_send_recv() modifies its
iov. The modification is undone at the end, so you seem to have
considered that a caller might be reusing it after and you can't "use it
up", but we still get problems with concurrent accesses.

Was it an intentional design decision that iov_send_recv() is the sole
owner of the iov and the caller must duplicate it if it's used elsewhere
concurrently?

Otherwise I would suggest to fix iov_send_recv(), and possibly try and
make all the qiov/iov arguments in the block layer const.

Kevin