| Message ID | 20180130062503.32596-1-famz@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | iotests: Fix CID for VMDK afl image | expand |
On 01/30/2018 12:25 AM, Fam Zheng wrote: > This reverts commit 76bf133c4 which updated the reference output, and > fixed the reference image, because the code path we want to exercise is > actually the invalid image size. > > The descriptor block in the image, which includes the CID to verify, has been > invalid since the reference image was added. Since commit 9877860e7bd we report > this error earlier than the "file too large", so 059.out mismatches. > > The binary change is generated along the operations of: > > $ bunzip2 afl9.vmdk.bz2 > $ qemu-img create -f vmdk fix.vmdk 1G > $ dd if=afl9.vmdk.bz2 of=fix.vmdk bs=512 count=1 conv=notrunc Is the .bz2 suffix spurious here? > $ mv fix.vmdk afl9.vmdk > $ bzip2 afl9.vmdk > > Signed-off-by: Fam Zheng <famz@redhat.com> > > --- > Reviewed-by: Eric Blake <eblake@redhat.com>
On Tue, Jan 30, 2018 at 9:48 PM, Eric Blake <eblake@redhat.com> wrote: > On 01/30/2018 12:25 AM, Fam Zheng wrote: >> This reverts commit 76bf133c4 which updated the reference output, and >> fixed the reference image, because the code path we want to exercise is >> actually the invalid image size. >> >> The descriptor block in the image, which includes the CID to verify, has been >> invalid since the reference image was added. Since commit 9877860e7bd we report >> this error earlier than the "file too large", so 059.out mismatches. >> >> The binary change is generated along the operations of: >> >> $ bunzip2 afl9.vmdk.bz2 >> $ qemu-img create -f vmdk fix.vmdk 1G >> $ dd if=afl9.vmdk.bz2 of=fix.vmdk bs=512 count=1 conv=notrunc > > Is the .bz2 suffix spurious here? Hmm, yes. I have no idea why it is here. :-/ Fam > >> $ mv fix.vmdk afl9.vmdk >> $ bzip2 afl9.vmdk >> >> Signed-off-by: Fam Zheng <famz@redhat.com> >> >> --- >> > > Reviewed-by: Eric Blake <eblake@redhat.com> > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org >
Am 30.01.2018 um 07:25 hat Fam Zheng geschrieben: > This reverts commit 76bf133c4 which updated the reference output, and > fixed the reference image, because the code path we want to exercise is > actually the invalid image size. > > The descriptor block in the image, which includes the CID to verify, has been > invalid since the reference image was added. Since commit 9877860e7bd we report > this error earlier than the "file too large", so 059.out mismatches. > > The binary change is generated along the operations of: > > $ bunzip2 afl9.vmdk.bz2 > $ qemu-img create -f vmdk fix.vmdk 1G > $ dd if=afl9.vmdk.bz2 of=fix.vmdk bs=512 count=1 conv=notrunc > $ mv fix.vmdk afl9.vmdk > $ bzip2 afl9.vmdk > > Signed-off-by: Fam Zheng <famz@redhat.com> Thanks, applied to the block branch. Kevin
On 2018-01-30 07:25, Fam Zheng wrote: > This reverts commit 76bf133c4 which updated the reference output, and > fixed the reference image, because the code path we want to exercise is > actually the invalid image size. > > The descriptor block in the image, which includes the CID to verify, has been > invalid since the reference image was added. Since commit 9877860e7bd we report > this error earlier than the "file too large", so 059.out mismatches. > > The binary change is generated along the operations of: > > $ bunzip2 afl9.vmdk.bz2 > $ qemu-img create -f vmdk fix.vmdk 1G > $ dd if=afl9.vmdk.bz2 of=fix.vmdk bs=512 count=1 conv=notrunc > $ mv fix.vmdk afl9.vmdk > $ bzip2 afl9.vmdk > > Signed-off-by: Fam Zheng <famz@redhat.com> > > --- > > v2: Fix commit message "qcow2 -> vmdk". [Kevin] > Revert 76bf133c4. Hmmmm, now this fails again on my 32 bit build. :-( The issue there is that you get a "Cannot allocate memory" when trying to open the file. My current fix was 2291712c39111a732 which simply converted that to "Invalid argument", but now it's getting a bit more complicated... Should I just continue to play the game and check the output for "Cannot allocate memory" and print exactly what the reference output is expecting...? Max
On Thu, Feb 1, 2018 at 2:58 AM, Max Reitz <mreitz@redhat.com> wrote: > On 2018-01-30 07:25, Fam Zheng wrote: >> This reverts commit 76bf133c4 which updated the reference output, and >> fixed the reference image, because the code path we want to exercise is >> actually the invalid image size. >> >> The descriptor block in the image, which includes the CID to verify, has been >> invalid since the reference image was added. Since commit 9877860e7bd we report >> this error earlier than the "file too large", so 059.out mismatches. >> >> The binary change is generated along the operations of: >> >> $ bunzip2 afl9.vmdk.bz2 >> $ qemu-img create -f vmdk fix.vmdk 1G >> $ dd if=afl9.vmdk.bz2 of=fix.vmdk bs=512 count=1 conv=notrunc >> $ mv fix.vmdk afl9.vmdk >> $ bzip2 afl9.vmdk >> >> Signed-off-by: Fam Zheng <famz@redhat.com> >> >> --- >> >> v2: Fix commit message "qcow2 -> vmdk". [Kevin] >> Revert 76bf133c4. > > Hmmmm, now this fails again on my 32 bit build. :-( > > The issue there is that you get a "Cannot allocate memory" when trying > to open the file. My current fix was 2291712c39111a732 which simply > converted that to "Invalid argument", but now it's getting a bit more > complicated... Should I just continue to play the game and check the > output for "Cannot allocate memory" and print exactly what the reference > output is expecting...? Ahhh. OK, then, with a big comment. I'd say let's just _notrun on 32 bit. Fam
On 2018-02-01 01:55, Fam Zheng wrote: > On Thu, Feb 1, 2018 at 2:58 AM, Max Reitz <mreitz@redhat.com> wrote: >> On 2018-01-30 07:25, Fam Zheng wrote: >>> This reverts commit 76bf133c4 which updated the reference output, and >>> fixed the reference image, because the code path we want to exercise is >>> actually the invalid image size. >>> >>> The descriptor block in the image, which includes the CID to verify, has been >>> invalid since the reference image was added. Since commit 9877860e7bd we report >>> this error earlier than the "file too large", so 059.out mismatches. >>> >>> The binary change is generated along the operations of: >>> >>> $ bunzip2 afl9.vmdk.bz2 >>> $ qemu-img create -f vmdk fix.vmdk 1G >>> $ dd if=afl9.vmdk.bz2 of=fix.vmdk bs=512 count=1 conv=notrunc >>> $ mv fix.vmdk afl9.vmdk >>> $ bzip2 afl9.vmdk >>> >>> Signed-off-by: Fam Zheng <famz@redhat.com> >>> >>> --- >>> >>> v2: Fix commit message "qcow2 -> vmdk". [Kevin] >>> Revert 76bf133c4. >> >> Hmmmm, now this fails again on my 32 bit build. :-( >> >> The issue there is that you get a "Cannot allocate memory" when trying >> to open the file. My current fix was 2291712c39111a732 which simply >> converted that to "Invalid argument", but now it's getting a bit more >> complicated... Should I just continue to play the game and check the >> output for "Cannot allocate memory" and print exactly what the reference >> output is expecting...? > > Ahhh. OK, then, with a big comment. > > I'd say let's just _notrun on 32 bit. Sounds OK, but how would we test that? uname? Or just _notrun when we see the ENOMEM message? Max
On 02/01/2018 11:59 AM, Max Reitz wrote: >>> Hmmmm, now this fails again on my 32 bit build. :-( >>> >>> The issue there is that you get a "Cannot allocate memory" when trying >>> to open the file. My current fix was 2291712c39111a732 which simply >>> converted that to "Invalid argument", but now it's getting a bit more >>> complicated... Should I just continue to play the game and check the >>> output for "Cannot allocate memory" and print exactly what the reference >>> output is expecting...? >> >> Ahhh. OK, then, with a big comment. >> >> I'd say let's just _notrun on 32 bit. > > Sounds OK, but how would we test that? uname? Or just _notrun when we > see the ENOMEM message? _notrun when you detect ENOMEM seems reasonable (the equivalent of exit status 77 in skipping a test in an automake context)
diff --git a/tests/qemu-iotests/059.out b/tests/qemu-iotests/059.out index 1ac5d56233..f6dce7947c 100644 --- a/tests/qemu-iotests/059.out +++ b/tests/qemu-iotests/059.out @@ -2358,5 +2358,5 @@ Offset Length Mapped to File 0x140000000 0x10000 0x50000 TEST_DIR/t-s003.vmdk === Testing afl image with a very large capacity === -qemu-img: Could not open 'TEST_DIR/afl9.IMGFMT': Could not open 'TEST_DIR/afl9.IMGFMT': Invalid argument +qemu-img: Can't get image size 'TEST_DIR/afl9.IMGFMT': File too large *** done
This reverts commit 76bf133c4 which updated the reference output, and fixed the reference image, because the code path we want to exercise is actually the invalid image size. The descriptor block in the image, which includes the CID to verify, has been invalid since the reference image was added. Since commit 9877860e7bd we report this error earlier than the "file too large", so 059.out mismatches. The binary change is generated along the operations of: $ bunzip2 afl9.vmdk.bz2 $ qemu-img create -f vmdk fix.vmdk 1G $ dd if=afl9.vmdk.bz2 of=fix.vmdk bs=512 count=1 conv=notrunc $ mv fix.vmdk afl9.vmdk $ bzip2 afl9.vmdk Signed-off-by: Fam Zheng <famz@redhat.com> --- v2: Fix commit message "qcow2 -> vmdk". [Kevin] Revert 76bf133c4. --- tests/qemu-iotests/059.out | 2 +- tests/qemu-iotests/sample_images/afl9.vmdk.bz2 | Bin 178 -> 618 bytes 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/qemu-iotests/sample_images/afl9.vmdk.bz2 b/tests/qemu-iotests/sample_images/afl9.vmdk.bz2 index 03615d36a12425cf4240bab86f4cfe648db14572..9fcd0af45a815431acf4689e0845ecf2d333cd58 100644 GIT binary patch literal 618 zcmV-w0+szjT4*^jL0KkKSvgW7ssIN3|NsBH-Q9UpfAhclU70`s-*NE~5QvC~h=_=Y zh>D2n*q*=vygR634445h35k;?00h9835kMW00004$iPepVE{Bqk)uhJ^wfGLr=)3s zhM5CR88jLh7)B;cA*K)*6GmuECPU3o4NWG5O#pg>Ak#xY8Z^<M8Z>CrMt}oD38Ns$ z02n}M0LdjZ&}cLPqd+nPKmn$j0iXe(02%-d27nnJriN-uE+X&cz@Bj4BBfd|yV!NB zwqkL}nW3AI5x^jp=t%^F1pxqp)v#n#)j$zcm1xqv(!$2d*5%vF{5RPWnOV8-^tE<( zU~%&}Y0uNu*9Wt=yS^8PkC&gPueZO%IG;aD{l#sG`<Af;l1Pnwpi9I75FkQ`LLhd8 z6(9f*2s+N5=%bwp80ddrD6>m4Ho*fsHXdM<jtl*zKvRiTx7Ugy1|Nl<Ns!z;1dvhy z=`SDHh~{u|1ZodC(_lzezQ)I*Kv2z|PZ@!SJjlVzwGdx2iu#W}dI{t+T&dDWT^LPy zg3NouEM=V~7GvZQS1CXy676F6mJXWGgW!KTr+E$OspGYCjWmuwa^<Bc>_(-i7fPIW zA+~n9iy_f)g8B2RILhd%F)dZ5f?7pFLw)@;Ncl<JE}gvMrfh{elT#3gLjY6r8xY4O z)UO#pv=WYptukn<DuoMH2ip%k?V^k!rjQirK^RC<Brw>3Bz9<|!xm0F{45K+gg8#n z4FNAJ!<X|3Vq+lyV4=xZ;>AN0<K=%c4A2ruB!4rGvWm!KFrvd4PyfZ-kxmpO4pfM$ EfLnqQYXATM literal 178 zcmV;j08RfwT4*^jL0KkKS>A08g#Z9x|HJ$H)ZJi0004xF0SE*D03g5s00IDLSQelF ziVX^$pfWNUJrmRhn2k52pQ;Rs0EQC;(S%|!m`2~BZ@b++;etskRJUVl!Kt)wu7?VN zl;%JdqX2?TgsNVJP?87M*MvL1qQnBkCES&?0@MeaN-bL4;bDzxmMm|da4fuh!=#fu g@i9R@5z!av{9tA<GGr!3hi~HUNT&)C8_l7xpl%OKQ2+n{