From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9ZN1-0006UA-LL for qemu-devel@nongnu.org; Tue, 22 Jul 2014 08:40:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X9ZMs-0004R9-Hs for qemu-devel@nongnu.org; Tue, 22 Jul 2014 08:40:39 -0400 Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:38749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9ZMs-0004R2-9U for qemu-devel@nongnu.org; Tue, 22 Jul 2014 08:40:30 -0400 Received: by mail-wi0-f171.google.com with SMTP id hi2so5909421wib.4 for ; Tue, 22 Jul 2014 05:40:29 -0700 (PDT) Date: Tue, 22 Jul 2014 13:40:26 +0100 From: Stefan Hajnoczi Message-ID: <20140722124026.GB21042@stefanha-thinkpad.redhat.com> References: <1403857452-23768-1-git-send-email-cnanakos@grnet.gr> <1403857452-23768-2-git-send-email-cnanakos@grnet.gr> <20140710002322.GA8058@localhost.localdomain> <53BE6546.5030704@grnet.gr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uQr8t48UFsdbeI+V" Content-Disposition: inline In-Reply-To: <53BE6546.5030704@grnet.gr> Subject: Re: [Qemu-devel] [PATCH v6 1/5] block: Support Archipelago as a QEMU block backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chrysostomos Nanakos Cc: kwolf@redhat.com, Jeff Cody , qemu-devel@nongnu.org, stefanha@redhat.com --uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 10, 2014 at 01:04:54PM +0300, Chrysostomos Nanakos wrote: > On 07/10/2014 03:23 AM, Jeff Cody wrote: > >On Fri, Jun 27, 2014 at 11:24:08AM +0300, Chrysostomos Nanakos wrote: > >>+err_exit: > >>+ __sync_add_and_fetch(&segreq->failed, 1); > >>+ if (segments_nr =3D=3D 1) { > >>+ if (__sync_add_and_fetch(&segreq->ref, -1) =3D=3D 0) { > >>+ g_free(segreq); > >>+ } > >>+ } else { > >>+ if ((__sync_add_and_fetch(&segreq->ref, -segments_nr + i)) =3D= =3D 0) { > >>+ g_free(segreq); > >>+ } > >>+ } > >Don't we run the risk of leaking segreq here? The other place this is > >freed is in xseg_request_handler(), but could we run into a race > >condition where 's->stopping' is true, or even xseg_receive() just does = not > >return a request? >=20 > If 's->stopping' is true means that _close() has been invoked. How QEMU > handles unserviced requests while in the meantime someone invokes _close(= )? > Does it wait for the requests to finish and then exits? Or it exits silen= tly > without checking for pending requests? >=20 > If xseg_receive() does not return an already submitted request then the > problem is located in Archipelago stack. Someone should check why the > pending requests are not serviced and resolve the problem. The question h= ere > is the same as before, how QEMU handles pending requests while in the > meantime invokes _close()? >=20 > Until all pending requests are serviced successfully or not, segreq > allocations will remain and not freed. Another approach could have been a > linked list that tracks all submitted requests and handle them accordingly > on _close(). >=20 > Suggestions here are more than welcome! bdrv_close() drains all requests before invoking .bdrv_close(). I think there is no race condition in that case. Stefan --uQr8t48UFsdbeI+V Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTzlu6AAoJEJykq7OBq3PIYagH/3LIHjD5oZEQnP9NdgG3pePf fGYQzNGp1h6fBVtF7cOunh3adl5pGbKWH13SRh+O0ZSgCmzSCNhRBmulip6GGHKe JPgqUoUHt44dTU+dfP3xiM181nFiInasnWrw2R6TMBMad75z2B+Ro2gyEFgLuxGQ J8uKYGNs2Wwm/wzuNk4DuHqA9GVa3GxLvTGr2ku/4C8XTWsBWWKhx1JmIKp33RCH gukgaQuPmWmrYe8wBbwLGheF6jY2JWF7kilDEpACr1VxDCfeRz+FtmTL6dmwBBZ/ FTS/Dfq3qQT0xBFO3F0UKvsoQHX4Qbg/UcWgrOyIQoFXjyI8dwdZZfK2gJy0Vbg= =/9Pd -----END PGP SIGNATURE----- --uQr8t48UFsdbeI+V--