1. 03 8月, 2017 8 次提交
  2. 02 8月, 2017 19 次提交
  3. 01 8月, 2017 3 次提交
    • M
      virNetDaemonCallInhibit: Call virNetDaemonGotInhibitReply properly · ace45e67
      Michal Privoznik 提交于
      So there are couple of issues here. Firstly, we never unref the
      @pendingReply and thus it leaks.
      
      ==13279== 144 (72 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 1,095 of 1,259
      ==13279==    at 0x4C2E080: calloc (vg_replace_malloc.c:711)
      ==13279==    by 0x781FA97: _dbus_pending_call_new_unlocked (in /usr/lib64/libdbus-1.so.3.14.11)
      ==13279==    by 0x7812A4C: dbus_connection_send_with_reply (in /usr/lib64/libdbus-1.so.3.14.11)
      ==13279==    by 0x56BEDF3: virNetDaemonCallInhibit (virnetdaemon.c:514)
      ==13279==    by 0x56BEF18: virNetDaemonAddShutdownInhibition (virnetdaemon.c:536)
      ==13279==    by 0x12473B: daemonInhibitCallback (libvirtd.c:742)
      ==13279==    by 0x1249BD: daemonRunStateInit (libvirtd.c:823)
      ==13279==    by 0x554FBCF: virThreadHelper (virthread.c:206)
      ==13279==    by 0x8F913D3: start_thread (in /lib64/libpthread-2.23.so)
      ==13279==    by 0x928DE3C: clone (in /lib64/libc-2.23.so)
      
      Secondly, while we send the message, we are suspended ('cos we're
      talking to a UNIX socket).  However, until we are resumed back
      again the reply might have came therefore subsequent
      dbus_pending_call_set_notify() has no effect and in fact the
      virNetDaemonGotInhibitReply() callback is never called. Thirdly,
      the dbus_connection_send_with_reply() has really stupid policy
      for return values. To cite the man page:
      
        Returns
            FALSE if no memory, TRUE otherwise.
      
      Yes, that's right. If anything goes wrong and it's not case of
      OOM then TRUE is returned, i.e. you're trying to pass FDs and
      it's not supported, or you're not connected, or anything else.
      Therefore, checking for return value of
      dbus_connection_send_with_reply() is not enoguh. We also have to
      check if @pendingReply is not NULL before proceeding any further.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ace45e67
    • M
      virCgroupValidateMachineGroup: Don't free @machinename · 3e609bf4
      Michal Privoznik 提交于
      We are given a string in @machinename, we never allocate it, just
      merely use it for reading. We should not free it otherwise it
      leads to double free:
      
      ==32191== Thread 17:
      ==32191== Invalid free() / delete / delete[] / realloc()
      ==32191==    at 0x4C2D1A0: free (vg_replace_malloc.c:530)
      ==32191==    by 0x54BBB84: virFree (viralloc.c:582)
      ==32191==    by 0x2BC04499: qemuProcessStop (qemu_process.c:6313)
      ==32191==    by 0x2BC500FF: processMonitorEOFEvent (qemu_driver.c:4724)
      ==32191==    by 0x2BC502FC: qemuProcessEventHandler (qemu_driver.c:4769)
      ==32191==    by 0x5550640: virThreadPoolWorker (virthreadpool.c:167)
      ==32191==    by 0x554FBCF: virThreadHelper (virthread.c:206)
      ==32191==    by 0x8F913D3: start_thread (in /lib64/libpthread-2.23.so)
      ==32191==    by 0x928DE3C: clone (in /lib64/libc-2.23.so)
      ==32191==  Address 0x31893d70 is 0 bytes inside a block of size 1,100 free'd
      ==32191==    at 0x4C2D1A0: free (vg_replace_malloc.c:530)
      ==32191==    by 0x54BBB84: virFree (viralloc.c:582)
      ==32191==    by 0x54C1936: virCgroupValidateMachineGroup (vircgroup.c:343)
      ==32191==    by 0x54C4B29: virCgroupNewDetectMachine (vircgroup.c:1550)
      ==32191==    by 0x2BBDDA29: qemuConnectCgroup (qemu_cgroup.c:972)
      ==32191==    by 0x2BC05DA7: qemuProcessReconnect (qemu_process.c:6822)
      ==32191==    by 0x554FBCF: virThreadHelper (virthread.c:206)
      ==32191==    by 0x8F913D3: start_thread (in /lib64/libpthread-2.23.so)
      ==32191==    by 0x928DE3C: clone (in /lib64/libc-2.23.so)
      ==32191==  Block was alloc'd at
      ==32191==    at 0x4C2BE80: malloc (vg_replace_malloc.c:298)
      ==32191==    by 0x4C2E35F: realloc (vg_replace_malloc.c:785)
      ==32191==    by 0x54BB492: virReallocN (viralloc.c:245)
      ==32191==    by 0x54BEDF2: virBufferGrow (virbuffer.c:150)
      ==32191==    by 0x54BF3B9: virBufferVasprintf (virbuffer.c:408)
      ==32191==    by 0x54BF324: virBufferAsprintf (virbuffer.c:381)
      ==32191==    by 0x55BB271: virDomainGenerateMachineName (domain_conf.c:27078)
      ==32191==    by 0x2BBD5B8F: qemuDomainGetMachineName (qemu_domain.c:9595)
      ==32191==    by 0x2BBDD9B4: qemuConnectCgroup (qemu_cgroup.c:966)
      ==32191==    by 0x2BC05DA7: qemuProcessReconnect (qemu_process.c:6822)
      ==32191==    by 0x554FBCF: virThreadHelper (virthread.c:206)
      ==32191==    by 0x8F913D3: start_thread (in /lib64/libpthread-2.23.so)
      
      Moreover, make the @machinename 'const char *' to mark it
      explicitly that we are not changing the passed string.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      3e609bf4
    • A
      news: Fix typo · 756dbf6b
      Andrea Bolognani 提交于
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      756dbf6b
  4. 31 7月, 2017 1 次提交
  5. 28 7月, 2017 6 次提交
  6. 27 7月, 2017 3 次提交