56a60dd...
by
"Justin M. Forbes" <email address hidden>
Version 0.14.1
76c9b33...
by
Christoph Hellwig <email address hidden>
virtio-blk: fail unaligned requests
Like all block drivers virtio-blk should not allow small than block size
granularity access. But given that the protocol specifies a
byte unit length field we currently accept such requests, which cause
qemu to abort() in lower layers. Add checks to the main read and
write handlers to catch them early.
Reported-by: Conor Murphy <email address hidden>
Tested-by: Conor Murphy <email address hidden>
Signed-off-by: Christoph Hellwig <email address hidden>
Reviewed-by: Stefan Hajnoczi <email address hidden>
Signed-off-by: Kevin Wolf <email address hidden>
The qed_bytes_to_clusters() function is normally used with size_t
lengths. Consistency check used it with file size length and therefore
failed on 32-bit hosts when the image file is 4 GB or more.
Make qed_bytes_to_clusters() explicitly 64-bit and update consistency
check to keep 64-bit cluster counts.
Reported-by: Michael Tokarev <email address hidden>
Signed-off-by: Stefan Hajnoczi <email address hidden>
Signed-off-by: Kevin Wolf <email address hidden>
419f1c3...
by
Michael Tokarev <email address hidden>
exit if -drive specified is invalid instead of ignoring the "wrong" -drive
This fixes the problem when qemu continues even if -drive specification
is somehow invalid, resulting in a mess. Applicable for both current
master and for stable-0.14 (and the same issue exist 0.13 and 0.12 too).
The prob can actually be seriuos: when you start guest with two drives
and make an error in the specification of one of them, and the guest
has something like a raid array on the two drives, guest may start failing
that array or kick "missing" drives which may result in a mess - this is
what actually happened to me, I did't want a resync at all, and a resync
resulted in re-writing (and allocating) a 4TB virtual drive I used for
testing, which in turn resulted in my filesystem filling up and whole
thing failing badly. Yes it was just testing VM, I experimented with
larger raid arrays, but the end result was quite, well, unexpected.
Signed-off-by: Michael Tokarev <email address hidden>
Acked-by: Jes Sorensen <email address hidden>
Signed-off-by: Kevin Wolf <email address hidden>
Do not delete BlockDriverState when deleting the drive
When removing a drive from the host-side via drive_del we currently have
the following path:
drive_del
qemu_aio_flush()
bdrv_close() // zaps bs->drv, which makes any subsequent I/O get
// dropped. Works as designed
drive_uninit()
bdrv_delete() // frees the bs. Since the device is still connected to
// bs, any subsequent I/O is a use-after-free.
The value of bs->drv becomes unpredictable on free. As long as it
remains null, I/O still gets dropped, however it could become non-null
at any point after the free resulting SEGVs or other QEMU state
corruption.
To resolve this issue as simply as possible, we can chose to not
actually delete the BlockDriverState pointer. Since bdrv_close()
handles setting the drv pointer to NULL, we just need to remove the
BlockDriverState from the QLIST that is used to enumerate the block
devices. This is currently handled within bdrv_delete, so move this
into its own function, bdrv_make_anon().
The result is that we can now invoke drive_del, this closes the file
descriptors and sets BlockDriverState->drv to NULL which prevents futher
IO to the device, and since we do not free BlockDriverState, we don't
have to worry about the copy retained in the block devices.
We also don't attempt to remove the qdev property since we are no longer
deleting the BlockDriverState on drives with associated drives. This
also allows for removing Drives with no devices associated either.
Reported-by: Markus Armbruster <email address hidden>
Signed-off-by: Ryan Harper <email address hidden>
Acked-by: Markus Armbruster <email address hidden>
Signed-off-by: Kevin Wolf <email address hidden>
f8a4bf5...
by
Michael Tokarev <email address hidden>
vnc: tight: Fix crash after 2GB of output
fix 2Gb integer overflow in in VNC tight and zlib encodings
As found by Roland Dreier <email address hidden> (excellent
catch!), when amount of VNC compressed data produced by zlib
and sent to client exceeds 2Gb, integer overflow occurs because
currently, we calculate amount of data produced at each step by
comparing saved total_out with new total_out, and total_out is
something which grows without bounds. Compare it with previous
avail_out instead of total_out, and leave total_out alone.
The same code is used in vnc-enc-tight.c and vnc-enc-zlib.c,
so fix both cases.
There, there's no actual need to save previous_out value, since
capacity-offset (which is how that value is calculated) stays
the same so it can be recalculated again after call to deflate(),
but whole thing becomes less readable this way.
b3d657b...
by
Atsushi Nemoto <email address hidden>
lan9118: Ignore write to MAC_VLAN1 register
On Mon, 4 Apr 2011 20:15:30 +0200, Aurelien Jarno <email address hidden> wrote:
> Is it really safe ignoring write to this register? If yes, it's probably
> a good idea to explain why in a comment. In any case, if supporting this
> register is easy to do, it would be the best option.
I think it is safe. Please see an updated comment below.
And though implementing this register might be possible, I suppose it
is not worth to supporting FrameTooLong detection, for now at least.
Since linux 2.6.38, smsc911x driver writes to VLAN1 registger.
Since this register only affects FrameTooLong detection, ignoring
write to this register should be safe.
Don't allow multiwrites against a block device without underlying medium
If the block device has been closed, we no longer have a medium to submit
IO against, check for this before submitting io. This prevents a segfault
further in the code where we dereference elements of the block driver.
Signed-off-by: Ryan Harper <email address hidden>
Reviewed-by: Stefan Hajnoczi <email address hidden>
Signed-off-by: Kevin Wolf <email address hidden>
d4b4ba0...
by
Bernhard Kohl <email address hidden>
lsi53c895a: add support for ABORT messages
If these messages are not handled correctly the guest driver may hang.
Always mandatory:
- ABORT
- BUS DEVICE RESET
Mandatory if tagged queuing is implemented (which disks usually do):
- ABORT TAG
- CLEAR QUEUE
Signed-off-by: Bernhard Kohl <email address hidden>
Signed-off-by: Aurelien Jarno <email address hidden>
(cherry picked from commit 508240c0daecdd62ab46727f37145f2dbb029ff7)
