From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIC9d-0001Qk-Gj for qemu-devel@nongnu.org; Mon, 02 Feb 2015 03:14:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIC9a-0003oK-9m for qemu-devel@nongnu.org; Mon, 02 Feb 2015 03:14:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45970) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIC9a-0003nw-2T for qemu-devel@nongnu.org; Mon, 02 Feb 2015 03:14:42 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t128EdNA022432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 2 Feb 2015 03:14:40 -0500 Date: Mon, 2 Feb 2015 09:14:34 +0100 From: Stefan Hajnoczi Message-ID: <20150202081434.GF4258@stefanha-thinkpad.fosdem.net> References: <20150129162509.GA32706@tesla.redhat.com> <20150130171521.GD24537@noname.redhat.com> <20150130184143.GA9654@tesla.redhat.com> <54CBDC49.6040305@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zs/RYxT/hKAHzkfQ" Content-Disposition: inline In-Reply-To: <54CBDC49.6040305@redhat.com> Subject: Re: [Qemu-devel] QEMU segfault: Booting an overlay with backing_file over NBD: nbd.c:nbd_receive_request():L756: read failed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Kevin Wolf , qemu-devel@nongnu.org, Kashyap Chamarthy --Zs/RYxT/hKAHzkfQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 30, 2015 at 02:32:25PM -0500, Max Reitz wrote: > Kevin, Stefan: The real problem is that block/nbd.c stores a BDRVNBDState > object in bs->opaque and passes &BDRVNBDState.client (an NbdClientSession > object) to the block/nbd-client.c functions. Those functions then receive > the BDS pointer from client->bs. If an NBD BDS is a root BDS (as in this > case), at some point a bdrv_swap() may happen (and it does happen here) > which leads to ((BDRVNBDState *)bs->opaque)->client.bs !=3D bs, and that's > where the segfault comes from (bdrv_get_aio_context() returns NULL). >=20 > One way to fix this real problem is to remove the BDS pointer from the > NbdClientSession and to always pass the BDS explicitly to the > block/nbd-client.c functions; the other is to always update the BDS point= er > in NbdClientSession in block/nbd.c. I'll try the former, and if it doesn't > work, will do the latter (if you don't object). Sounds good. On a related note I asked John Snow to look at QED and vvfat's =2Ebdrv_rebind() usage. I think we can get rid of that API after propagating BlockDriverState *bs arguments to QED and vvfat functions. Stefan --Zs/RYxT/hKAHzkfQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUzzHqAAoJEJykq7OBq3PIXGIIAK8IZA618UUQ37c+f6NmW3+b vnC38janF0KZaIVBC/Xouf2R0z1T00J6VM8cGd3i2iFVOZuEYjV0++tfIXrDvdSK kXRMdqnZQOaPaIWOPgvU4827XZcsxHikoQiugHR5LdE6fQdmvPw6XBsOoffT9A1s eu0PXYHEK1A3pSJRs9QUr9VmaYUID1YCcoyGKBar/n9kX0v2pjTHSM0mCnoyOb4Q RowQd5GKCLbYQfjle5x5mnVEe3dn4W3kxM9BNZuCneP25jzE6o372laPOyFY/6vQ qnnXJ7NUakSeHX6qKHvQazAgze2i5hsCjh5GKSW9CLFAigIk+XrkcJ3to8ME4nU= =pNmL -----END PGP SIGNATURE----- --Zs/RYxT/hKAHzkfQ--