remote_daemon_stream: Fix @client locking in daemonStreamFilter()

When dispatching a message read from client it is first passed
through registered filters. If one of the filters consumes the
message no further processing of the message is done. However,
the filter callbacks are called with the client object locked.
This breaks lock ordering in case of virStream filter, we always
acquire stream private data lock without the client object
locked. In other words, the daemonStreamFilter() does not follow
the lock ordering.

Signed-off-by: LanceLiu <liu.lance.89@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This commit is contained in:
LanceLiu 2019-11-19 19:39:50 +08:00 committed by Michal Privoznik
parent 3a085d221e
commit 8ecab214de
2 changed files with 6 additions and 1 deletions

View File

@ -286,14 +286,16 @@ daemonStreamEvent(virStreamPtr st, int events, void *opaque)
* -1 on fatal client error
*/
static int
daemonStreamFilter(virNetServerClientPtr client G_GNUC_UNUSED,
daemonStreamFilter(virNetServerClientPtr client,
virNetMessagePtr msg,
void *opaque)
{
daemonClientStream *stream = opaque;
int ret = 0;
virObjectUnlock(client);
virMutexLock(&stream->priv->lock);
virObjectLock(client);
if (msg->header.type != VIR_NET_STREAM &&
msg->header.type != VIR_NET_STREAM_HOLE)

View File

@ -40,6 +40,9 @@ typedef void (*virNetServerClientDispatchFunc)(virNetServerClientPtr client,
virNetMessagePtr msg,
void *opaque);
/*
* @client is locked when this callback is called
*/
typedef int (*virNetServerClientFilterFunc)(virNetServerClientPtr client,
virNetMessagePtr msg,
void *opaque);