All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Jackson <ian.jackson@citrix.com>
To: Paul Durrant <pdurrant@amazon.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Wei Liu <wl@xen.org>
Subject: Re: [Xen-devel] [PATCH v5 4/7] libxl: add infrastructure to track and query 'recent' domids
Date: Mon, 17 Feb 2020 17:42:55 +0000	[thread overview]
Message-ID: <24138.53407.680649.217122@mariner.uk.xensource.com> (raw)
In-Reply-To: <20200131150149.2008-5-pdurrant@amazon.com>

Paul Durrant writes ("[PATCH v5 4/7] libxl: add infrastructure to track and query 'recent' domids"):
> A domid is considered recent if the domain it represents was destroyed
> less than a specified number of seconds ago. For debugging and/or testing
> purposes the number can be set using the environment variable
> LIBXL_DOMID_REUSE_TIMEOUT. If the variable does not exist then a default
> value of 60s is used.
> 
> Whenever a domain is destroyed, a time-stamped record will be written into
> a history file (/var/run/xen/domid-history). To avoid the history file
> growing too large, any records with time-stamps that indicate that the
> age of a domid has exceeded the re-use timeout will also be purged.
> 
> A new utility function, libxl__is_recent_domid(), has been added. This
> function reads the same history file checking whether a specified domid
> has a record that does not exceed the re-use timeout. Since this utility
> function does not write to the file, no records are actually purged by it.

Thanks for this.  Sorry for the delay in reviewing it.

I'm afraid I still have some comments about error handling etc.

> +int libxl_clear_domid_history(libxl_ctx *ctx);

I think this needs a clear doc comment saying it is for use in host
initialisation only.  If it is run with any domains running, or
concurrent libxl processes, things may malfunction.

> +static bool libxl__read_recent(FILE *f, unsigned long *sec,
> +                               unsigned int *domid)
> +{
> +    int n;
> +
> +    assert(f);
> +
> +    n = fscanf(f, "%lu %u", sec, domid);
> +    if (n == EOF)
> +        return false;

Missing error handling in case of read error.

> +    else if (n != 2) /* malformed entry */
> +        *domid = INVALID_DOMID;

Both call sites for this function have open-coded checks for this
return case, where they just go round again.  I think
libxl__read_recent should handle this itself, factoring the common
code into this function and avoiding that special case.

> +    return true;

I think this function should return an rc.  It could signal EOF by
setting *domid to INVALID_DOMID maybe, and errors by returning
ERROR_FAIL.

> +static bool libxl__write_recent(FILE *f, unsigned long sec,
> +                                unsigned int domid)
> +{
> +    assert(f);

This is rather pointless.  Please drop it.

> +    assert(libxl_domid_valid_guest(domid));

I doubt this is really needed but I don't mind it if you must.

> +    return fprintf(f, "%lu %u\n", sec, domid) > 0;

Wrong error handling.  This function should return rc.  fprintf
doesn't return a boolean.  Something should log errno (with LOGE
probably) if fprintf fails.

> +static int libxl__mark_domid_recent(libxl__gc *gc, uint32_t domid)
> +{
> +    long timeout = libxl__get_domid_reuse_timeout();
> +    libxl__flock *lock;

Please initialise lock = NULL so that it is easy to see that the out
block is correct.

(See tools/libxl/CODING_STYLE where this is discussed.)

> +    char *old, *new;
> +    FILE *of = NULL, *nf = NULL;
> +    struct timespec ts;
> +    int rc = ERROR_FAIL;

Please do not set rc to ERROR_FAIL like this.  Leave it undefined.
Set it on each exit path.  (If you are calling a function that returns
an rc, you can put it in rc, and then test rc and goto out without
assignment.)

(Again, see tools/libxl/CODING_STYLE where this is discussed.)

> +    lock = libxl__lock_domid_history(gc);
> +    if (!lock) {
> +        LOGED(ERROR, domid, "failed to acquire lock");
> +        goto out;
> +    }
> +
> +    old = libxl__domid_history_path(gc, NULL);
> +    of = fopen(old, "r");
> +    if (!of && errno != ENOENT)
> +        LOGED(WARN, domid, "failed to open '%s'", old);

This fopen code and its error handling is still duplicated between
libxl__mark_domid_recent and libxl__is_domid_recent.  I meant for you
to factor it out.  Likewise the other duplicated code in these two
functions.  I want there to be nothing duplicated that can be written
once.

Also failure to open the file should be an error, resulting failure of
this function and the whole surrounding operation, not simply produce
a warning in some logfile where it will be ignored.

> +        while (libxl__read_recent(of, &sec, &val)) {
> +            if (!libxl_domid_valid_guest(val))
> +                continue; /* Ignore invalid entries */
> +
> +            if (ts.tv_sec - sec > timeout)
> +                continue; /* Ignore expired entries */
> +
> +            if (!libxl__write_recent(nf, sec, val)) {
> +                LOGED(ERROR, domid, "failed to write to '%s'", new);
> +                goto out;
> +            }
> +        }
> +        if (ferror(of)) {
> +            LOGED(ERROR, domid, "failed to read from '%s'", old);
> +            goto out;
> +        }

Oh, wait, here is one of the missing pieces of error handling ?
Please put it where it belongs, next to the corresponding call.

> +    if (of && fclose(of) == EOF) {
> +        LOGED(ERROR, domid, "failed to close '%s'", old);

I don't see how of would be NULL here.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-02-17 17:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 15:01 [Xen-devel] [PATCH v5 0/7] xl/libxl: domid allocation/preservation changes Paul Durrant
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 1/7] libxl: add definition of INVALID_DOMID to the API Paul Durrant
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 2/7] libxl_create: make 'soft reset' explicit Paul Durrant
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 3/7] libxl: generalise libxl__domain_userdata_lock() Paul Durrant
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 4/7] libxl: add infrastructure to track and query 'recent' domids Paul Durrant
2020-02-17 17:42   ` Ian Jackson [this message]
2020-02-18  9:24     ` Durrant, Paul
2020-02-18 11:38       ` Ian Jackson
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 5/7] libxl: allow creation of domains with a specified or random domid Paul Durrant
2020-01-31 17:22   ` Jason Andryuk
2020-02-03  7:50     ` Durrant, Paul
2020-02-17 17:51   ` Ian Jackson
2020-02-18  9:31     ` Durrant, Paul
2020-02-18 11:17       ` Ian Jackson
2020-02-18 11:25         ` Durrant, Paul
2020-02-18 11:47           ` Ian Jackson
2020-02-18 11:57             ` Durrant, Paul
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 6/7] xl.conf: introduce 'domid_policy' Paul Durrant
2020-01-31 15:01 ` [Xen-devel] [PATCH v5 7/7] xl: allow domid to be preserved on save/restore or migrate Paul Durrant
2020-02-17 17:55   ` Ian Jackson
2020-02-17 14:21 ` [Xen-devel] [PATCH v5 0/7] xl/libxl: domid allocation/preservation changes Durrant, Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24138.53407.680649.217122@mariner.uk.xensource.com \
    --to=ian.jackson@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=pdurrant@amazon.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.