1. 06 2月, 2015 5 次提交
    • P
      Merge remote-tracking branch 'remotes/armbru/tags/pull-cov-model-2015-02-05' into staging · 651621b7
      Peter Maydell 提交于
      coverity: Improve and extend model
      
      # gpg: Signature made Thu 05 Feb 2015 16:20:49 GMT using RSA key ID EB918653
      # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>"
      # gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>"
      
      * remotes/armbru/tags/pull-cov-model-2015-02-05:
        MAINTAINERS: Add myself as Coverity model maintainer
        coverity: Model g_free() isn't necessarily free()
        coverity: Model GLib string allocation partially
        coverity: Improve model for GLib memory allocation
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      651621b7
    • M
    • M
      coverity: Model g_free() isn't necessarily free() · 7ad4c720
      Markus Armbruster 提交于
      Memory allocated with GLib needs to be freed with GLib.  Freeing it
      with free() instead of g_free() is a common error.  Harmless when
      g_free() is a trivial wrapper around free(), which is commonly the
      case.  But model the difference anyway.
      
      In a local scan, this flags four ALLOC_FREE_MISMATCH.  Requires
      --enable ALLOC_FREE_MISMATCH, because the checker is still preview.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      7ad4c720
    • M
      coverity: Model GLib string allocation partially · e4b77daa
      Markus Armbruster 提交于
      Without a model, Coverity can't know that the result of g_strdup()
      needs to be fed to g_free().
      
      One way to get such a model is to scan GLib, build a derived model
      file with cov-collect-models, and use that when scanning QEMU.
      Unfortunately, the Coverity Scan service we use doesn't support that.
      
      Thus, we're stuck with the other way: write a user model.  Doing that
      for all of GLib is hardly practical.  I'm doing it for the "String
      Utility Functions" we actually use that return dynamically allocated
      strings.
      
      In a local scan, this flags 20 additional RESOURCE_LEAKs.  The ones I
      checked look genuine.
      
      It also loses a NULL_RETURNS about ppce500_init() using
      qemu_find_file() without error checking.  I don't understand why.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      e4b77daa
    • M
      coverity: Improve model for GLib memory allocation · 9d7a4c66
      Markus Armbruster 提交于
      In current versions of GLib, g_new() may expand into g_malloc_n().
      When it does, Coverity can't see the memory allocation, because we
      don't model g_malloc_n().  Similarly for g_new0(), g_renew(),
      g_try_new(), g_try_new0(), g_try_renew().
      
      Model g_malloc_n(), g_malloc0_n(), g_realloc_n().  Model
      g_try_malloc_n(), g_try_malloc0_n(), g_try_realloc_n() by adding
      indeterminate out of memory conditions on top.
      
      To avoid undue duplication, replace the existing models for g_malloc()
      & friends by trivial wrappers around g_malloc_n() & friends.
      
      In a local scan, this flags four additional RESOURCE_LEAKs and one
      NULL_RETURNS.
      
      The NULL_RETURNS is a false positive: Coverity can now see that
      g_try_malloc(l1_sz * sizeof(uint64_t)) in
      qcow2_check_metadata_overlap() may return NULL, but is too stupid to
      recognize that a loop executing l1_sz times won't be entered then.
      
      Three out of the four RESOURCE_LEAKs appear genuine.  The false
      positive is in ppce500_prep_device_tree(): the pointer dies, but a
      pointer to a struct member escapes, and we get the pointer back for
      freeing with container_of().  Too funky for Coverity.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      9d7a4c66
  2. 05 2月, 2015 33 次提交
  3. 04 2月, 2015 2 次提交
    • P
      Merge remote-tracking branch 'remotes/rth/tags/pull-tg-s390-20150203' into staging · ec6f25e7
      Peter Maydell 提交于
      s390 translator bug fixes
      
      # gpg: Signature made Tue 03 Feb 2015 20:39:15 GMT using RSA key ID 4DD0279B
      # gpg: Good signature from "Richard Henderson <rth7680@gmail.com>"
      # gpg:                 aka "Richard Henderson <rth@redhat.com>"
      # gpg:                 aka "Richard Henderson <rth@twiddle.net>"
      
      * remotes/rth/tags/pull-tg-s390-20150203:
        target-s390x: fix and optimize slb* and slbg* computation of carry/borrow flag
        target-s390x: support OC and NC in the EX instruction
        disas/s390.c: Remove unused variables
        target-s390x: Mark check_privileged() as !CONFIG_USER_ONLY
        target-s390: Implement ECAG
        target-s390: Implement LURA, LURAG, STURG
        target-s390: Fix STURA
        target-s390: Fix STIDP
        target-s390: Implement EPSW
        target-s390: Implement SAM specification exception
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      ec6f25e7
    • T
      target-s390x: fix and optimize slb* and slbg* computation of carry/borrow flag · 9ef14736
      Torbjorn Granlund 提交于
      This patch fixes the bug with borrow_in being set incorrectly, but it
      also simplifies the logic to be much more plain, improving speed.  It
      fixes both the 32-bit SLB* and 64-bit SLBG*.
      
      The SLBG* change has been well-tested.  I haven't tested the SLB* change
      explicitly, but the code was copy-pasted from the tested code.
      
      The error of these functions' current implementations would not likely
      be triggered by compiler-generated code, since the only error was in the
      state of the carry/borrow flag.  Compilers rarely generate an
      instruction sequence such as carry-set -> carry-set-and-use ->
      carry-use.
      
      (With Paolo's fix and mine, there are still a couple of failures from
      GMP's testsuite, but they are almost surely due to incorrect code
      generation from gcc 4.9.  But since this gcc is running under qemu, it
      might be qemu bugs.  I intend to investigate this.)
      Signed-off-by: NTorbjorn Granlund <torbjorng@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NRichard Henderson <rth@twiddle.net>
      9ef14736