On 03/28/2018 11:18 AM, Daniel P. Berrangé wrote:
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- src/remote/remote_daemon.h | 1 + src/remote/remote_daemon_dispatch.c | 19 +++++++++++-------- src/rpc/gendispatch.pl | 6 ++++++ 3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/src/remote/remote_daemon.h b/src/remote/remote_daemon.h index 31f433c15d..60be78fe0b 100644 --- a/src/remote/remote_daemon.h +++ b/src/remote/remote_daemon.h @@ -75,6 +75,7 @@ struct daemonClientPrivate { */ virConnectPtr conn; virConnectPtr interfaceConn; + virConnectPtr networkConn;
daemonClientStreamPtr streams; }; diff --git a/src/remote/remote_daemon_dispatch.c b/src/remote/remote_daemon_dispatch.c index 7971646c28..d0bc474850 100644 --- a/src/remote/remote_daemon_dispatch.c +++ b/src/remote/remote_daemon_dispatch.c @@ -1699,7 +1699,7 @@ remoteClientFreePrivateCallbacks(struct daemonClientPrivate *priv)
Trying to forward think - will there ever come a day when priv->conn == NULL, but priv->*Conn != NULL? The caller is gated on priv->conn... IOW: Do we need to separate this one out a bit now If not, then consider this Reviewed-by: John Ferlan <jferlan@redhat.com> If so, then probably need to see adjustment... John
DEREG_CB(priv->conn, priv->domainEventCallbacks, priv->ndomainEventCallbacks, virConnectDomainEventDeregisterAny, "domain"); - DEREG_CB(priv->conn, priv->networkEventCallbacks, + DEREG_CB(priv->networkConn, priv->networkEventCallbacks, priv->nnetworkEventCallbacks, virConnectNetworkEventDeregisterAny, "network"); DEREG_CB(priv->conn, priv->storageEventCallbacks,
[...]