[libvirt] [PATCH v3 6/6] remote/rpc: Use virNetServerGetProgram() to determine the program

Pavel Hrdina phrdina at redhat.com
Thu Nov 14 08:20:22 UTC 2019


On Wed, Nov 13, 2019 at 07:12:34PM +0100, Marc Hartmayer wrote:
> On Wed, Nov 13, 2019 at 09:52 AM +0100, Pavel Hrdina <phrdina at redhat.com> wrote:
> > On Fri, Nov 01, 2019 at 06:35:48PM +0100, Marc Hartmayer wrote:
> >> Use virNetServerGetProgram() to determine the virNetServerProgram
> >> instead of using hard coded global variables. This allows us to remove
> >> the global variables @remoteProgram and @qemuProgram as they're now no
> >> longer necessary.
> >> 
> >> Signed-off-by: Marc Hartmayer <mhartmay at linux.ibm.com>
> 
> […snip…]
> 
> >>                                             virNetMessageErrorPtr rerr)
> >>  {
> >>      int rv = -1;
> >> @@ -4180,6 +4180,12 @@ remoteDispatchConnectRegisterCloseCallback(virNetServerPtr server G_GNUC_UNUSED,
> >>      struct daemonClientPrivate *priv =
> >>          virNetServerClientGetPrivateData(client);
> >>      virConnectPtr conn = remoteGetHypervisorConn(client);
> >> +    virNetServerProgramPtr program;
> >> +
> >> +    if (!(program = virNetServerGetProgram(server, msg))) {
> >> +        virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("no matching program found"));
> >> +        goto cleanup;
> >> +    }
> >
> > This doesn't look right.  If the function fails we will jump to cleanup
> > where we will try to unlock &priv->lock.  This has to happen after we
> > acquire that lock.
> >
> > Pavel
> 
> Yep, will fix that as well. Shall I directly return in the error case or
> jump to another label (e.g. 'cleanup_unlock')?

Returning directly would not work properly as well, we call
virNetMessageSaveError() in case of error in the cleanup section.

Another label would work.

> Or do see any reason why we should hold the priv->lock during the
> virNetServerGetProgram call?

We don't have to hold the lock for virNetServerGetProgram(), it just
makes the function easier to follow as there will be only one cleanup
and I don't see any harm of holding the lock for that function call as
well if the function will later wait for the same lock.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20191114/9dead71e/attachment-0001.sig>


More information about the libvir-list mailing list