From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YRJKG-0003Dm-9A for qemu-devel@nongnu.org; Fri, 27 Feb 2015 06:43:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YRJKC-0001BF-9n for qemu-devel@nongnu.org; Fri, 27 Feb 2015 06:43:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YRJKC-0001BA-2L for qemu-devel@nongnu.org; Fri, 27 Feb 2015 06:43:20 -0500 Date: Fri, 27 Feb 2015 12:43:13 +0100 From: Kevin Wolf Message-ID: <20150227114313.GF3174@noname.str.redhat.com> References: <1424208819-10306-1-git-send-email-mreitz@redhat.com> <20150227112559.GB20354@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20150227112559.GB20354@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [PATCH] block/vdi: Fix locking for parallel requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Stefan Weil , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 27.02.2015 um 12:25 hat Stefan Hajnoczi geschrieben: > On Tue, Feb 17, 2015 at 04:33:39PM -0500, Max Reitz wrote: > > Concurrently modifying the bmap is not a good idea; this patch adds a > > lock for it. See https://bugs.launchpad.net/qemu/+bug/1422307 for what > > can go wrong without. > >=20 > > Signed-off-by: Max Reitz > > --- > > block/vdi.c | 23 ++++++++++++++++++++--- > > 1 file changed, 20 insertions(+), 3 deletions(-) >=20 > Max: Ping? >=20 > Would be nice to merge a new revision with Paolo's comment addressed. > Let's get it in for hard freeze (March 3rd) so that it gets testing > during the release candidate phase. And we still don't know _why_ this fixes anything. If we're locking just because that's the obvious thing to try and it appears to fix something, I would be much more comfortable with one lock at the very start of the function, and one unlock at its very end, plus a TODO comment that someone should figure out why it's needed. Kevin --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJU8FhRAAoJEH8JsnLIjy/WBO8P/23CEdlAt55BDc0/P40JkokJ +5r6cXrS7slARZOp3+9Vb0bgY9Wg+EDsvsZEDXgKX2okHJSOlteFIFde3lx4shpg eopNQtMR1wEaI8bhz/t72XMIbLUB45aNfvfJM1nMr/KNZDApbedfhTcXkHMdE54A Qik75LokH+LJmpCwj1LrwG83xhYU/ZyHDzYveeSrYjzhmgsEq4RbMaYF8QrVtClT dgjBXoy55LUDuekCzXJRwEcTGJ46Q0twuVaOTp0Beci3ksYyNaqmyqOZUZ25OcF5 7KE/sfcUjGCXGV57OzJq12XpynMaQD3GX2swTnmJ9QGvJ+IiFlz9yDKmzSfzqhgG YgVX5pYIf0lOny+CJc4s22QeH87WLKc5xa0dZAhdH6fnu/FI2VDY5/gTVh+Hg+EO 9waKJ+5sZtrDnWbukgSd1IrHj5EXEXE1k1KRsp/gpAc0HLqzbfE9Zuo9HyfGcYne JxGtOvqMKihpnlFpYNqlU8GO+Yw0hr1tmOP/MGFtvM4WgIgFgrtgDkE/J4vXG/S9 UgHFRUinW3Q+Juw8OtTFxrObUbLspaZt+eULXCKBxVNsoR1UOAm6lWyYfT4Csk6l /5zrB1bdnCyBRXk1SlfOko4Ob4OGb9QYFsg06prUlVjIVM/gGJPgdZQt+Nmd6fPX 6kvYKNKOAc76xTDFeZCY =3INq -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM--