1. 03 8月, 2017 20 次提交
  2. 02 8月, 2017 19 次提交
  3. 01 8月, 2017 1 次提交
    • 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