[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-block] qemu-iotest 059 vmdk failure
From: |
John Snow |
Subject: |
[Qemu-block] qemu-iotest 059 vmdk failure |
Date: |
Tue, 21 Nov 2017 19:07:39 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
The last sub-test in 059, which uses an AFL fuzzer image to test for how
a large L1 table of a specific size is handled has a slight regression.
Previously, QEMU expects -EFBIG to come out the vmdk_open call. Now, we
get -EINVAL. Not too ominous.
Now, QEMU actually allocates the L1 table (1.6GB) and gets a little
further, only to eventually trip up here:
#0 vmdk_read_cid (bs=0x555555d4c5a0, parent=0, pcid=0x555555d5786c) at
/home/bos/jhuston/src/qemu/block/vmdk.c:272
#1 0x00005555555947cb in vmdk_open (bs=0x555555d4c5a0,
options=0x555555d509b0, flags=65536, errp=0x7fffffffd950)
at /home/bos/jhuston/src/qemu/block/vmdk.c:989
where p_name is NULL, so we return -EINVAL back up the stack. We get all
the way through vmdk_open_sparse --> vmdk_open_vmdk4 before we
eventually catch an error in the header and return a fairly nondescript
EINVAL which doesn't tell the end user much.
We don't error out earlier because the vmdk_add_extent function checks
to see if we are exceeding 512*1024*1024 ... entries, which means that
later when we get to vmdk_init_tables, we do multiply this number by
four again, so our actual maximum L1 table size in terms of bytes is
2GiB, not 512MiB.
(Maybe you knew that, I didn't, enjoy useless facts. The comment in code
seemed to suggest the size was a literal size in bytes, but it's treated
more as the number of L1 entries, which is different.)
Anyway, this still seems slightly silly that we don't catch obviously
bogus images a little sooner, so I wanna rewind and see why we don't get
-EFBIG anymore.
The output changes as of 9877860e which adds the p_name check, so we
appear to actually be failing even earlier, just not before we
apparently load up a 2GB L1 table from a file that clocks in at less
than 1KB.
(Wait, why does that work? Am I tracing this wrong? -EOUTTATIME)
Anyway, we can fix this by amending the reference test output, or we
might want to shore up the vmdk input validation a bit.
Not a regression, and the test was broken in v2.10 anyway, so not
critical to fix during rc phase, I think.
Anyway, I need to go prepare some food for Thanksgiving, so I won't come
back to this one for a few days. If it's not important to anyone else,
I'll get back around to it eventually.
--js
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-block] qemu-iotest 059 vmdk failure,
John Snow <=