diff mbox

[v4,2/5] libxl: Fix libxl_set_memory_target return value

Message ID 1450441425-10755-3-git-send-email-george.dunlap@eu.citrix.com (mailing list archive)
State New, archived
Headers show

Commit Message

George Dunlap Dec. 18, 2015, 12:23 p.m. UTC
libxl_set_memory_target seems to have the following return values:

* 1 on failure, if the failure happens because of a xenstore error *or* invalid target

* -1 if the setmaxmem hypercall

* -errno if the set_pod_target hypercall target fails

* 0 on success

Make it consistently return ERROR_FAIL on failure, unless the
parameters were invalid, in which case return ERROR_INVAL.

In accordance with CODING_SYTLE:

1. Leave rc uninitialized, and set when an error is detected

2. Use 'r' for return values to functions whose return values are a
different error space (like xc_domain_setmaxmem and
xc_domain_set_pod_target), or where a failure means retry, rather than
fail the whole function (libxl__fill_dom0_memory_info), to reduce the
risk that

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
v4:
 - Use 'r' instead of 'lrc'
 - Set 'rc' before jumping to error path, rather than initializing at the beginning
 - Move removal of xc_domain_getinfolist to another patch

CC: Ian Campbell <ian.campbell@citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl.c | 29 +++++++++++++++++++----------
 1 file changed, 19 insertions(+), 10 deletions(-)

Comments

Ian Jackson Jan. 4, 2016, 5:37 p.m. UTC | #1
George Dunlap writes ("[PATCH v4 2/5] libxl: Fix libxl_set_memory_target return value"):
> 2. Use 'r' for return values to functions whose return values are a
> different error space (like xc_domain_setmaxmem and
> xc_domain_set_pod_target), or where a failure means retry, rather than
> fail the whole function (libxl__fill_dom0_memory_info), to reduce the
> risk that

The use of `r' to contain libxl__fill_dom0_memory_info's return value
is IMO confusing and contrary to CODING_STYLE.

Sorry that I didn't spot this last sentence in your point `2' when
reading ijc's review of your v3, where ijc suggested `r'.

> v4:
>  - Use 'r' instead of 'lrc'

Can you go back to `lrc' for just that one use ?  I think that would
be analogous with CODING_STYLE's suggestion to use `rc' for libxl
error codes.


>          abort_transaction = 1;
> +        rc = ERROR_FAIL;

There is an awful lot of this.  I won't object to this in your patch,
as what you have is an improvement, but:

Every `goto out' here is preceded by `abort_transaction = 1'.

If you converted this function to:
  - use libxl__xs_transaction_start et al
  - in the intended pattern as shown in its doc comment
  - use the `out' path only for errors
  - unconditionally call libxl__xs_transaction_abort in the out
    block
  - call libxl__xs_transaction_commit in the success path

Then you could abolish `abort_transaction' and remove all assignments
to it.  You could also abolish `out_no_transaction'.

If you were feeling really gung-ho you could get rid of `goto retry'
and replace it with a loop.

Ian.
Ian Campbell Jan. 5, 2016, 2:54 p.m. UTC | #2
On Mon, 2016-01-04 at 17:37 +0000, Ian Jackson wrote:
> George Dunlap writes ("[PATCH v4 2/5] libxl: Fix libxl_set_memory_target
> return value"):
> > 2. Use 'r' for return values to functions whose return values are a
> > different error space (like xc_domain_setmaxmem and
> > xc_domain_set_pod_target), or where a failure means retry, rather than
> > fail the whole function (libxl__fill_dom0_memory_info), to reduce the
> > risk that
> 
> The use of `r' to contain libxl__fill_dom0_memory_info's return value
> is IMO confusing and contrary to CODING_STYLE.
> 
> Sorry that I didn't spot this last sentence in your point `2' when
> reading ijc's review of your v3, where ijc suggested `r'.

And for my part sorry for not spotting the libxl_* in with the xc_*, or I'd
have (hopefully) have thought to mention it.

> 
> > v4:
> >  - Use 'r' instead of 'lrc'
> 
> Can you go back to `lrc' for just that one use ?  I think that would
> be analogous with CODING_STYLE's suggestion to use `rc' for libxl
> error codes.

I was never quite sure what the "l" was supposed to reference, local?

> 
> 
> >          abort_transaction = 1;
> > +        rc = ERROR_FAIL;
> 
> There is an awful lot of this.  I won't object to this in your patch,
> as what you have is an improvement, but:
> 
> Every `goto out' here is preceded by `abort_transaction = 1'.
> 
> If you converted this function to:
>   - use libxl__xs_transaction_start et al
>   - in the intended pattern as shown in its doc comment
>   - use the `out' path only for errors
>   - unconditionally call libxl__xs_transaction_abort in the out
>     block
>   - call libxl__xs_transaction_commit in the success path
> 
> Then you could abolish `abort_transaction' and remove all assignments
> to it.  You could also abolish `out_no_transaction'.
> 
> If you were feeling really gung-ho you could get rid of `goto retry'
> and replace it with a loop.
> 
> Ian.
Ian Jackson Jan. 5, 2016, 3:21 p.m. UTC | #3
Ian Campbell writes ("Re: [PATCH v4 2/5] libxl: Fix libxl_set_memory_target return value"):
> On Mon, 2016-01-04 at 17:37 +0000, Ian Jackson wrote:
> > Can you go back to `lrc' for just that one use ?  I think that would
> > be analogous with CODING_STYLE's suggestion to use `rc' for libxl
> > error codes.
> 
> I was never quite sure what the "l" was supposed to reference, local?

It seems to mean `local' to me.  I was going to suggest `lrc' for this
variable name even before I saw that it had already been `lrc' in a
previous patch, which suggests it's a local maximum in probability
space...

Ian.
diff mbox

Patch

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a36101d..d05e58e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4742,7 +4742,7 @@  int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
         int32_t target_memkb, int relative, int enforce)
 {
     GC_INIT(ctx);
-    int rc = 1, abort_transaction = 0;
+    int rc, abort_transaction = 0, r;
     uint64_t memorykb;
     uint32_t videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
@@ -4770,15 +4770,15 @@  retry_transaction:
     if (!target && !domid) {
         if (!xs_transaction_end(ctx->xsh, t, 1))
             goto out_no_transaction;
-        rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb,
+        r = libxl__fill_dom0_memory_info(gc, &current_target_memkb,
                                           &current_max_memkb);
-        if (rc < 0)
-            goto out_no_transaction;
+        if (r < 0) { rc = ERROR_FAIL; goto out_no_transaction; }
         goto retry_transaction;
     } else if (!target) {
         LOGE(ERROR, "cannot get target memory info from %s/memory/target",
              dompath);
         abort_transaction = 1;
+        rc = ERROR_FAIL;
         goto out;
     } else {
         current_target_memkb = strtoul(target, &endptr, 10);
@@ -4786,6 +4786,7 @@  retry_transaction:
             LOGE(ERROR, "invalid memory target %s from %s/memory/target\n",
                  target, dompath);
             abort_transaction = 1;
+            rc = ERROR_FAIL;
             goto out;
         }
     }
@@ -4794,6 +4795,7 @@  retry_transaction:
         LOGE(ERROR, "cannot get memory info from %s/memory/static-max",
              dompath);
         abort_transaction = 1;
+        rc = ERROR_FAIL;
         goto out;
     }
     memorykb = strtoul(memmax, &endptr, 10);
@@ -4801,6 +4803,7 @@  retry_transaction:
         LOGE(ERROR, "invalid max memory %s from %s/memory/static-max\n",
              memmax, dompath);
         abort_transaction = 1;
+        rc = ERROR_FAIL;
         goto out;
     }
 
@@ -4820,6 +4823,7 @@  retry_transaction:
             "memory_dynamic_max must be less than or equal to"
             " memory_static_max\n");
         abort_transaction = 1;
+        rc = ERROR_INVAL;
         goto out;
     }
 
@@ -4827,33 +4831,36 @@  retry_transaction:
         LOG(ERROR, "new target %d for dom0 is below the minimum threshold",
             new_target_memkb);
         abort_transaction = 1;
+        rc = ERROR_INVAL;
         goto out;
     }
 
     if (enforce) {
         memorykb = new_target_memkb + videoram;
-        rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
+        r = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
                 LIBXL_MAXMEM_CONSTANT);
-        if (rc != 0) {
+        if (r != 0) {
             LOGE(ERROR,
                  "xc_domain_setmaxmem domid=%u memkb=%"PRIu64" failed ""rc=%d\n",
                  domid,
                  memorykb + LIBXL_MAXMEM_CONSTANT,
-                 rc);
+                 r);
             abort_transaction = 1;
+            rc = ERROR_FAIL;
             goto out;
         }
     }
 
-    rc = xc_domain_set_pod_target(ctx->xch, domid,
+    r = xc_domain_set_pod_target(ctx->xch, domid,
             (new_target_memkb + LIBXL_MAXMEM_CONSTANT) / 4, NULL, NULL, NULL);
-    if (rc != 0) {
+    if (r != 0) {
         LOGE(ERROR,
              "xc_domain_set_pod_target domid=%d, memkb=%d ""failed rc=%d\n",
              domid,
              new_target_memkb / 4,
-             rc);
+             r);
         abort_transaction = 1;
+        rc = ERROR_FAIL;
         goto out;
     }
 
@@ -4867,6 +4874,8 @@  retry_transaction:
                      "%"PRIu32, new_target_memkb / 1024);
     libxl_dominfo_dispose(&ptr);
 
+    rc = 0;
+
 out:
     if (!xs_transaction_end(ctx->xsh, t, abort_transaction)
         && !abort_transaction)