Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. May 04, 2011
  3. May 03, 2011
    • Christoph Hellwig's avatar
      virtio-blk: fail unaligned requests · 76c9b330
      Christoph Hellwig authored 
      
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: default avatarConor Murphy <conor_murphy_virt@hotmail.com>
Tested-by: default avatarConor Murphy <conor_murphy_virt@hotmail.com>
Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Reviewed-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      76c9b330
    • Stefan Hajnoczi's avatar
      qed: Fix consistency check on 32-bit hosts · 9b33410d
      Stefan Hajnoczi authored 
      
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: default avatarMichael Tokarev <mjt@tls.msk.ru>
Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      9b33410d
    • Michael Tokarev's avatar
      exit if -drive specified is invalid instead of ignoring the "wrong" -drive · 419f1c35
      Michael Tokarev authored 
      
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: default avatarMichael Tokarev <mjt@tls.msk.ru>
Acked-by: default avatarJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      419f1c35
    • Michael S. Tsirkin's avatar
      vhost: fix dirty page handling · fc5c4a7a
      Michael S. Tsirkin authored 
      
vhost was passing a physical address to cpu_physical_memory_set_dirty,
which is wrong: we need to translate to ram address first.

Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>

Note: this lead to crashes during migration, so the patch
is needed on the stable branch too.
      fc5c4a7a
    • Ryan Harper's avatar
      Do not delete BlockDriverState when deleting the drive · 22da30fc
      Ryan Harper authored 
      
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: default avatarMarkus Armbruster <armbru@redhat.com>
Signed-off-by: default avatarRyan Harper <ryanh@us.ibm.com>
Acked-by: default avatarMarkus Armbruster <armbru@redhat.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      22da30fc
  5. Apr 10, 2011
    • Michael Tokarev's avatar
      vnc: tight: Fix crash after 2GB of output · f8a4bf59
      Michael Tokarev authored 
      
fix 2Gb integer overflow in in VNC tight and zlib encodings

As found by Roland Dreier <roland@purestorage.com> (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.

Reported-by: default avatarRoland Dreier <roland@purestorage.com>
Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
Signed-off-by: default avatarCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      f8a4bf59
  7. Apr 09, 2011
    • Atsushi Nemoto's avatar
      lan9118: Ignore write to MAC_VLAN1 register · b3d657bc
      Atsushi Nemoto authored 
      
On Mon, 4 Apr 2011 20:15:30 +0200, Aurelien Jarno <aurelien@aurel32.net> 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.

Thank you for comments.

>8---------------------------------------------------------------------
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Tue, 5 Apr 2011 23:12:07 +0900
Subject: [PATCH] lan9118: Ignore write to MAC_VLAN1 register

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.

Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: default avatarAurelien Jarno <aurelien@aurel32.net>
(cherry picked from commit a0313c00)
      b3d657bc
  9. Apr 04, 2011
  11. Apr 01, 2011
  13. Mar 29, 2011
  15. Mar 06, 2011
  17. Mar 04, 2011
  19. Mar 03, 2011
  21. Feb 25, 2011
  23. Feb 20, 2011
  25. Feb 16, 2011
  27. Feb 14, 2011
  29. Feb 11, 2011
  31. Feb 09, 2011
  33. Feb 08, 2011