1. 12 2月, 2019 33 次提交
  2. 09 2月, 2019 2 次提交
    • C
      docs: storage: owner/group default to libvirtd UID/GID · e00771df
      Cole Robinson 提交于
      Commit fafcc818 changed the docs to say that when creating a
      pool directory or file volume with no owner/group specified, they
      will be inherited from the parent directory. This isn't correct
      now and doesn't seem to have ever been correct
      
      In reality default owner/group is whatever UID/GID libvirtd is
      running as
      Signed-off-by: NCole Robinson <crobinso@redhat.com>
      e00771df
    • N
      rpc: client: stream: fix multi thread abort/finish · d63c82df
      Nikolay Shirokovskiy 提交于
      If 2 threads call abort for example then one of them
      will hang because client will send 2 abort messages and
      server will reply only on first of them, the second will be
      ignored. And on server reply client changes the state only
      one of abort message to complete, the second will hang forever.
      There are other similar issues.
      
      We should complete all messages waiting reply if we got
      error or expected abort/finish reply from server. Also if one
      thread send finish and another abort one of them will win
      the race and server will either abort or finish stream. If
      stream is aborted then thread requested finishing should report
      error. In order to archive this let's keep stream closing reason
      in @closed field. If we receive VIR_NET_OK message for stream
      then stream is finished if oldest (closest to queue end) message
      in stream queue is finish message and stream is aborted if oldest
      message is abort message. Otherwise it is protocol error.
      
      By the way we need to fix case of receiving VIR_NET_CONTINUE
      message. Now we take oldest message in queue and check if
      this is dummy message. If one thread first sends abort and
      second thread then receives data then oldest message is abort
      message and second thread won't be notified when data arrives.
      Let's find oldest dummy message instead.
      Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      d63c82df
  3. 08 2月, 2019 5 次提交
    • N
      rpc: client stream: dispose private data on stream dispose · fbcb7386
      Nikolay Shirokovskiy 提交于
      If we call virStreamFinish and virStreamAbort from 2 distinct
      threads for example we can have access to freed memory.
      Because when virStreamFinish finishes for example virStreamAbort
      yet to be finished and it access virNetClientStreamPtr object
      in stream->privateData.
      
      Also it does not make sense to clear @driver field. After
      stream is finished/aborted it is better to have appropriate
      error message instead of "unsupported error".
      
      This commit reverts [1] or virNetClientStreamPtr and
      virStreamPtr will never be unrefed due to cyclic dependency.
      Before this patch we don't have leaks because all execution
      paths we call virStreamFinish or virStreamAbort.
      
      [1] 8b6ffe40 : virNetClientStreamNew: Track origin stream
      Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      fbcb7386
    • N
      rpc: client: don't set incomingEOF on errors · d962f56f
      Nikolay Shirokovskiy 提交于
      This mixing errors and EOF condition in one flag is odd.
      Instead let's check st->err.code where appropriate.
      Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      d962f56f
    • N
      rpc: client: incapsulate error checks · ad063f61
      Nikolay Shirokovskiy 提交于
      Checking virNetClientStreamRaiseError without client lock
      is racy which is fixed in [1] for example. Thus let's remove such checks
      when we are sending message to server. And in other cases
      (like virNetClientStreamRecvHole for example) let's move the check
      into client stream code.
      
      virNetClientStreamRecvPacket already have stream lock so we could
      introduce another error checking function like virNetClientStreamRaiseErrorLocked
      but as error is set when both client and stream lock are hold we
      can remove locking from virNetClientStreamRaiseError because all
      callers hold either client or stream lock.
      
      Also let's split virNetClientStreamRaiseErrorLocked into checking
      state function and checking message send status function. They are
      same yet.
      
      [1] 1b6a29c21: rpc: fix race on stream abort/finish and server side abort
      Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      ad063f61
    • N
    • N
      rpc: fix propagation of errors from server · 4deed5f3
      Nikolay Shirokovskiy 提交于
      Stream server error is not propagated if thread does not have the buck.
      In case we have the buck we are ok due to the code added in [1].
      
      Let's check for stream error on all paths. Now we don't need
      to raise error in virNetClientCallDispatchStream.
      
      Old code reported error only if the first message in wait
      queue awaits reply. It is odd as depends on wait queue
      situation. For example if we have only TX
      message in queue and in one iteration loop both send the
      message and receive error then thread sending TX message did
      not receive the error. Next if we have RX message (first)
      and TX message (second) in queue and in one iteration
      loop both send the TX message and receive error then
      thread sending TX message received error. In short
      it was inconsistent. Let's report error whenever
      we received it and for every type of message as it makes
      sense to report errors as early as possible.
      
      [1] 16c6e2b4: Fix propagation of RPC errors from streams
      Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      4deed5f3