qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] e3f9fe: cutils: unsigned int parsing function


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] e3f9fe: cutils: unsigned int parsing functions
Date: Mon, 04 Feb 2013 14:30:12 -0800

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: e3f9fe2d404ca10153e95499ece111c077b6690a
      
https://github.com/qemu/qemu/commit/e3f9fe2d404ca10153e95499ece111c077b6690a
  Author: Eduardo Habkost <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M include/qemu-common.h
    M tests/Makefile
    A tests/test-cutils.c
    M util/cutils.c

  Log Message:
  -----------
  cutils: unsigned int parsing functions

There are lots of duplicate parsing code using strto*() in QEMU, and
most of that code is broken in one way or another. Even the visitors
code have duplicate integer parsing code[1]. This introduces functions
to help parsing unsigned int values: parse_uint() and parse_uint_full().

Parsing functions for signed ints and floats will be submitted later.

parse_uint_full() has all the checks made by opts_type_uint64() at
opts-visitor.c:

 - Check for NULL (returns -EINVAL)
 - Check for negative numbers (returns -EINVAL)
 - Check for empty string (returns -EINVAL)
 - Check for overflow or other errno values set by strtoll() (returns
   -errno)
 - Check for end of string (reject invalid characters after number)
   (returns -EINVAL)

parse_uint() does everything above except checking for the end of the
string, so callers can continue parsing the remainder of string after
the number.

Unit tests included.

[1] string-input-visitor.c:parse_int() could use the same parsing code
    used by opts-visitor.c:opts_type_int(), instead of duplicating that
    logic.

Signed-off-by: Eduardo Habkost <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Laszlo Ersek <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


  Commit: 8f302cb0900ba7f38b62da5759f07b77483d6fb9
      
https://github.com/qemu/qemu/commit/8f302cb0900ba7f38b62da5759f07b77483d6fb9
  Author: Eduardo Habkost <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M vl.c

  Log Message:
  -----------
  vl.c: Fix off-by-one bug when handling "-numa node" argument

The numa_add() code was unconditionally adding 1 to the get_opt_name()
return value, making it point after the end of the string if no ','
separator is present.

Example of weird behavior caused by the bug:

  $ qemu-img create -f qcow2 
this-file-image-has,cpus=5,mem=1000,in-its-name.qcow2 5G
  Formatting 'this-file-image-has,cpus=5,mem=1000,in-its-name.qcow2', fmt=qcow2 
size=5368709120 encryption=off cluster_size=65536
  $ ./x86_64-softmmu/qemu-system-x86_64 -S -monitor stdio -numa node 
'this-file-image-has,cpus=5,mem=1000,in-its-name.qcow2'
  QEMU 1.3.50 monitor - type 'help' for more information
  (qemu) info numa
  1 nodes
  node 0 cpus: 0
  node 0 size: 1000 MB
  (qemu)

This changes the code to nove the pointer only if ',' is found.

Signed-off-by: Eduardo Habkost <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


  Commit: 12e53a9d59c8cb272a423e1db036324579a3c697
      
https://github.com/qemu/qemu/commit/12e53a9d59c8cb272a423e1db036324579a3c697
  Author: Eduardo Habkost <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M vl.c

  Log Message:
  -----------
  vl.c: Abort on unknown -numa option type

Abort in case an invalid -numa option is provided, instead of silently
ignoring it.

Signed-off-by: Eduardo Habkost <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


  Commit: ca4c6d363153f19abf3ffdf0ca1532daa581867d
      
https://github.com/qemu/qemu/commit/ca4c6d363153f19abf3ffdf0ca1532daa581867d
  Author: Eduardo Habkost <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M vl.c

  Log Message:
  -----------
  vl.c: Check for NUMA node limit inside numa_add()

Instead of checking the limit before calling numa_add(), check the limit
only when we already know we're going to add a new node.

Signed-off-by: Eduardo Habkost <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


  Commit: e4ce85b25838694d2d7396b5e969eb4830329631
      
https://github.com/qemu/qemu/commit/e4ce85b25838694d2d7396b5e969eb4830329631
  Author: Eduardo Habkost <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M vl.c

  Log Message:
  -----------
  vl.c: numa_add(): Validate nodeid before using it

Without this check, QEMU will corrupt memory if a too-large nodeid is
provided in the command-line. e.g.:

  -numa node,mem=...,cpus=...,nodeid=65

This changes nodenr to unsigned long long, to avoid integer conversion
issues when converting the strtoull() result to int.

Signed-off-by: Eduardo Habkost <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


  Commit: 5f1399651eaab1b04e49107250d182968a227aa6
      
https://github.com/qemu/qemu/commit/5f1399651eaab1b04e49107250d182968a227aa6
  Author: Eduardo Habkost <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M vl.c

  Log Message:
  -----------
  vl.c: Use parse_uint_full() for NUMA nodeid

This should catch many kinds of errors that the current code wasn't
checking for:

 - Values that can't be parsed as a number
 - Negative values
 - Overflow
 - Empty string

Signed-off-by: Eduardo Habkost <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


  Commit: 845e5bf9cd49873c72f84796cabf107c3f520f37
      
https://github.com/qemu/qemu/commit/845e5bf9cd49873c72f84796cabf107c3f520f37
  Author: Eduardo Habkost <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M vl.c

  Log Message:
  -----------
  vl.c: Extract -numa "cpus" parsing to separate function

This will make it easier to refactor that code later.

Signed-off-by: Eduardo Habkost <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


  Commit: c881e20eed4911ab6f8c674f2b1bf225a2cdde71
      
https://github.com/qemu/qemu/commit/c881e20eed4911ab6f8c674f2b1bf225a2cdde71
  Author: Eduardo Habkost <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M vl.c

  Log Message:
  -----------
  vl.c: validate -numa "cpus" parameter properly

- Accept empty strings without aborting
- Use parse_uint*() to parse numbers
- Abort if anything except '-' or end-of-string is found after the first
  number.
- Check for endvalue < value

Also change the MAX_CPUMASK_BITS warning message from "A max of %d CPUs
are supported in a guest" to "qemu: NUMA: A max of %d VCPUs are
supported".

Signed-off-by: Eduardo Habkost <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


  Commit: ded67782e6d06069873adce7f9074d273ae75760
      
https://github.com/qemu/qemu/commit/ded67782e6d06069873adce7f9074d273ae75760
  Author: Michael Roth <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M hw/acpi_piix4.c

  Log Message:
  -----------
  acpi_piix4: fix segfault migrating from 1.2

b0b873a07872f7ab7f66f259c73fb9dd42aa66a9 bumped the vmstate version and
introduced an old-style load function to handle migration from prior
(<= 1.2) versions.

The load function passes the top-level PIIX4PMState pointer to
vmstate_load_state() to handle nested structs for APMState and
pci_status, which leads to corruption of the top-level PIIX4PMState,
since pointers to the nested structs are expected.

A segfault can be fairly reliably triggered by migrating from 1.2 and
issuing a reset, which will trigger a number of QOM operations which
rely on the now corrupted ObjectClass/Object members.

Fix this by passing in the expected pointers for vmstate_load_state().

Cc: address@hidden
Signed-off-by: Michael Roth <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


  Commit: 0123c486367ab77c3c5ed349616a862eb474a03f
      
https://github.com/qemu/qemu/commit/0123c486367ab77c3c5ed349616a862eb474a03f
  Author: Anthony Liguori <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M target-s390x/helper.c

  Log Message:
  -----------
  s390x: silence warning from GCC on uninitialized values

As best I can tell, this is a false positive.

  address@hidden qemu-s390]$ make
    CC    s390x-softmmu/target-s390x/helper.o
  /home/aliguori/git/qemu/target-s390x/helper.c: In function ‘do_interrupt’:
  /home/aliguori/git/qemu/target-s390x/helper.c:673:17: error: ‘addr’ may be 
used uninitialized in this function [-Werror=maybe-uninitialized]
  /home/aliguori/git/qemu/target-s390x/helper.c:620:20: note: ‘addr’ was 
declared here
  /home/aliguori/git/qemu/target-s390x/helper.c:673:17: error: ‘mask’ may be 
used uninitialized in this function [-Werror=maybe-uninitialized]
  /home/aliguori/git/qemu/target-s390x/helper.c:620:14: note: ‘mask’ was 
declared here
  cc1: all warnings being treated as errors
  make[1]: *** [target-s390x/helper.o] Error 1
  make: *** [subdir-s390x-softmmu] Error 2

Cc: Cornelia Huck <address@hidden>
Cc: Stefan Weil <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


  Commit: b22dd1243f38286263d40496ce5298a8a7d96eea
      
https://github.com/qemu/qemu/commit/b22dd1243f38286263d40496ce5298a8a7d96eea
  Author: Stefan Weil <address@hidden>
  Date:   2013-02-04 (Mon, 04 Feb 2013)

  Changed paths:
    M target-s390x/helper.c

  Log Message:
  -----------
  target-s390x: Fix wrong comparison in interrupt handling

gcc with -Wextra complains about an ordered pointer comparison:

target-s390x/helper.c:660:27: warning:
 ordered comparison of pointer with integer zero [-Wextra]

Obviously the index was missing in the code.

Signed-off-by: Stefan Weil <address@hidden>
Signed-off-by: Anthony Liguori <address@hidden>


Compare: https://github.com/qemu/qemu/compare/ff057ccb07f0...b22dd1243f38

reply via email to

[Prev in Thread] Current Thread [Next in Thread]