[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] nwfilter: cleanup return codes in nwfilter subsystem

On 12/08/2011 06:19 PM, Eric Blake wrote:
On 11/23/2011 02:19 PM, Stefan Berger wrote:
This patch cleans up return codes in the nwfilter subsystem.
Resuming where I left off last time...

Index: libvirt-acl/src/conf/nwfilter_params.c
@@ -505,25 +505,25 @@ virNWFilterHashTablePut(virNWFilterHashT
          if (copyName) {
              name = strdup(name);
              if (!name)
-                return 1;
+                return -1;
virNWFilterDetermineMissingVarsRec() has an unchecked call to this
function, meaning that an OOM error can go undetected in that call site.

putting a virReportOOMError() into this one...

All other calls to this function look sanely converted.

@@ -640,7 +640,7 @@ virNWFilterHashTablePutAll(virNWFilterHa
      return 0;

-    return 1;
+    return -1;
All callers look sanely converted.

Index: libvirt-acl/src/nwfilter/nwfilter_gentech_driver.c
--- libvirt-acl.orig/src/nwfilter/nwfilter_gentech_driver.c
+++ libvirt-acl/src/nwfilter/nwfilter_gentech_driver.c
@@ -106,7 +106,7 @@ virNWFilterRuleInstAddData(virNWFilterRu
Comment prior to the function needs an update.

Thanks. Fixed.

      if (VIR_REALLOC_N(res->data, res->ndata+1)<  0) {
-        return 1;
+        return -1;
All callers look sanely converted.

@@ -151,28 +151,28 @@ virNWFilterVarHashmapAddStdValues(virNWF
      if (macaddr) {
          val = virNWFilterVarValueCreateSimple(macaddr);
          if (!val)
-            return 1;
+            return -1;
Comment prior to the function needs an update.  All callers correctly

@@ -649,7 +649,7 @@ virNWFilterInstantiate(virNWFilterTechDr
      virNWFilterHashTablePtr missing_vars = virNWFilterHashTableCreate(0);
      if (!missing_vars) {
-        rc = 1;
+        rc = -1;
This one calls through a callback that I did not audit:
         rc = techdriver->applyNewRules(ifname, nptrs, ptrs);
ebiptablesApplyNewRules is being called. The whole ebiptables driver has only -1 as failure codes now. So should be ok.

but assuming the callback is okay (or that you change things to ensure
rc is -1 even if the callback returns positive), then clients of this
look okay.

@@ -792,7 +792,7 @@ __virNWFilterInstantiateFilter(bool tear
                                 _("Could not get access to ACL tech "
                                 "driver '%s'"),
-        return 1;
+        return -1;
Ultimately called via virNWFilterInstantiateFilterLate, in turn called
by nwfilter_learnipaddr.c:learnIPAddressThread, which collects the
return value and prints it in a VIR_DEBUG but does nothing if the value
was negative.  Is that a problem?
Well, if the instantiation for any reason fails, then the code currently 'downs' the interface. I didn't know how else it should react since this path is invoked in a thread and tearing down the VM would be too severe.
Also called by the .instantiateFilter callback installed by
nwfilter_driver.c, which feeds virDomainConfNWFilterInstantiate, and all
callers look clean.

@@ -1012,7 +1012,7 @@ int virNWFilterRollbackUpdateFilter(cons
                                 _("Could not get access to ACL tech "
                                 "driver '%s'"),
-        return 1;
+        return -1;
Should this function be static?  No one outside of gentech_driver calls
it.  At any rate, callers inside the file are sane.

Yes, indeed. I changed it now to be static.

@@ -1038,7 +1038,7 @@ virNWFilterTearOldFilter(virDomainNetDef
                                 _("Could not get access to ACL tech "
                                 "driver '%s'"),
-        return 1;
+        return -1;
Same comments about static, and sane usage.

Also changed this one.@@ -530,7 +527,7 @@ learnIPAddressThread(void *arg)
          if (techdriver->applyBasicRules(req->ifname,
-                                        req->macaddr)) {
+                                        req->macaddr)<  0) {
I didn't audit where this callback came from, but assume it was okay.

ebtablesApplyBasicRules now returns -1 in case of failure, so it's ok.
@@ -3111,7 +3123,7 @@ ebtablesApplyBasicRules(const char *ifna
          virNWFilterReportError(VIR_ERR_INTERNAL_ERROR, "%s",
                                 _("cannot create rules since ebtables tool is "
-        return 1;
+        return -1;
Comment before function needs touch up.  Otherwise looks sane.

Fixed. Thanks.

@@ -4086,7 +4100,7 @@ ebiptablesDriverInit(bool privileged)
                                 _("firewall tools were not found or "
                                   "cannot be used"));
-        return ENOTSUP;
+        return -ENOTSUP;
Looks sane.

Overall, I found one or two nits between my two-stage review, but they
seemed easy to fix.

ACK.  Up to you if you want to post a delta to this patch for your
touchups, or just go ahead and commit, since I know you have other
patches backed up behind this one.

I went ahead and pushed the patch. Thanks for this thorough review with all the cross-checking and looking through the function descriptions.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]