From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anqMF-000466-3w for qemu-devel@nongnu.org; Wed, 06 Apr 2016 12:31:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anqME-0006vp-9i for qemu-devel@nongnu.org; Wed, 06 Apr 2016 12:31:07 -0400 Date: Wed, 6 Apr 2016 18:30:56 +0200 From: Kevin Wolf Message-ID: <20160406163056.GL5098@noname.redhat.com> References: <1459848109-29756-1-git-send-email-silbe@linux.vnet.ibm.com> <1459848109-29756-7-git-send-email-silbe@linux.vnet.ibm.com> <57053631.5010009@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <57053631.5010009@redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 6/7] qemu-iotests: 141: reduce likelihood of race condition on systems with fast IO List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Tu Bo , qemu-devel@nongnu.org, qemu-block@nongnu.org, Sascha Silbe --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 06.04.2016 um 18:15 hat Max Reitz geschrieben: > On 05.04.2016 11:21, Sascha Silbe wrote: > > On systems with fast IO, qemu-io may write more than 1 MiB before > > receiving the block-job-cancel command, causing the test case to fail. > >=20 > > 141 is inherently racy, but we can at least reduce the likelihood of the > > job completing before the cancel command arrives by bumping the size of > > the data getting written; we'll try 32 MiB for a start. >=20 > Hm, interesting. I tried to prevent this by setting the block jobs' > speed to 1, which should make it stop after the block job has processed > the first block of data. >=20 > I won't oppose this patch, because if it fixes things for you, that's > good. But I don't think it should be necessary. We don't generally change test cases when they fail. Making a test case pass doesn't "fix things" per se. It only helps when the failure is a false positive. In this case, it looks like there might be a problem with block job throttling, so maybe we should look into that before changing the test? Kevin > > Once we actually move enough data around for the block job not to > > complete prematurely, the test will still fail because the offset value > > in the BLOCK_JOB_CANCELLED event will vary. Since this is more or less > > inherent to the nature of this event, we just replace it with a fixed > > value globally (in _filter_qmp), the same way we handle timestamps. > >=20 > > Signed-off-by: Sascha Silbe > > Reviewed-by: Bo Tu > > --- > > tests/qemu-iotests/141 | 11 ++++++----- > > tests/qemu-iotests/141.out | 24 ++++++++++++------------ > > tests/qemu-iotests/common.filter | 1 + > > 3 files changed, 19 insertions(+), 17 deletions(-) >=20 --azLHFNyN32YCQGCU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJXBTnAAAoJEH8JsnLIjy/W48EP/3Z9pJB8AnLH8ZaNwmZx5oBP y9/iw3MJEXXQhsVgQSqvZMnTnFrPV5ZYQZhNLRkKO4NvR7sZ1uEBAFwGQB+nqvQC rub5dPKs5FitYQjXINw9/czMHcrv+ZNVpeJ8uuYqU4+1ZeDSrY+2ZVvr7NyS/MqC a4++ZEHjDQEP1srgzDcVdj9rBSq2R+lj0i/KACazpYjbFWi/HXo7cB2tCUfjAAZ2 PvuY6FmA7U6R5xVZG92idqJhZUGKpRr9iT8ot5LZ0ZW1IX/wzdWBpxvE5hl8KPVo ZkZbalq5oAZ5Oo/aT6AlU3m4/RZGzZw8mV7TEGz4F6FN6ssAIXYTh/a0eupWzKn5 amPuCD51R/IPuGHzvoiyc353Ucrs/Zu/vz72w5cXFwtd25jpZK5IzV7S6qtLMCV0 OUGjF+hs0gHeoHFAd+RvVrxuYaqEl01y7Z1RFENOB5lVtieVPAkBNxt8u65H8Xnm gXhHM21Itr3YxC2zPLZCDX4BHYbkzycz0y5YGRMn/OzyyclEAKRG95EcBNNkv8kx T3YoRqdmdhn4Vb1Bhg2VKyZBbpq9jtHZcQWmaZoboH+96eqjHsXIUUG+i7ywqDDi /49KA0s2bZDtI79cMmkccl+QmLHbbj60VGaDYVIlpmhgoysa4cxURAdsfAelNNeg oZeBpO+o0bUAsPMYIX5m =7Jjm -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU--