From: Jim Fehlig <jfehlig@novell.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>
Subject: Re: [PATCH] libxc: reset completed flag in restore_ctx
Date: Tue, 24 May 2011 09:12:47 -0600 [thread overview]
Message-ID: <4DDBCAEF.9030401@novell.com> (raw)
In-Reply-To: <1306224788.20576.109.camel@zakaz.uk.xensource.com>
Ian Campbell wrote:
> On Tue, 2011-05-24 at 00:05 +0100, Jim Fehlig wrote:
>
>> # HG changeset patch
>> # User Jim Fehlig <jfehlig@novell.com>
>> # Date 1306191873 21600
>> # Node ID f94242f20cdaee81d28f68df38d5a98f8fd9947d
>> # Parent fb517cc27adef3a7ad548e7397e02e1414132ead
>> libxc: reset completed flag in restore_ctx
>>
>> Long running libxl/libxc apps such as libvirt segfault when
>> attempting multiple restores. The completed flag in restore_ctx
>> structure is set at completion of first restore. Subsequent
>> restores do not load any pages and result in the segfault.
>>
>> Reset completed flag at start of restore.
>>
>
> Seems reasonable. However, we have:
> static struct restore_ctx _ctx = {
> .live_p2m = NULL,
> .p2m = NULL,
> };
> static struct restore_ctx *ctx = &_ctx;
> [...]
> /* For info only */
> ctx->nr_pfns = 0;
>
> i.e. we initialise the different subsets of the fields in two separate
> places. Perhaps we should just add a memset?
>
> BTW, those static variables are pretty disgusting and are going to cause
> trouble for users which deal with >1 domain at a time.
>
Heh, I was thinking about this on my way to the office today ...
> It's not clear that there is any reason for it to be a static variable
> anyway. It comes from 20545:cc7d66ba0dad which says: "pass the
> restore_context through function and allocate the context on the restore
> function stack." but, presumably by mistake, retains the static
> modifiers from the global variable. The same is true of the save side.
>
> So how about this instead (untested but seemingly sane...):
>
Yes, it looks sane to me and has now been tested. I did several
save/restore of both pv and hvm domains through libvirt libxl driver.
Tested-by: Jim Fehlig <jfehlig@novell.com>
Regards,
Jim
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1306224654 -3600
> # Node ID 13599c2c82d8bdbfc73611fed9a1bc2aebfa275c
> # Parent 9cf8d38260606de37826b76334028114feff6131
> libxc: xc_domain_{save,restore}: remove static variables
>
> 20544:ad9d75d74bd5 and 20545:cc7d66ba0dad seemingly intended to change these
> global static variables into stack variables but didn't remove the static
> qualifier.
>
> Also zero the entire struct once with memset rather than clearing fields
> piecemeal in two different places.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> diff -r 9cf8d3826060 -r 13599c2c82d8 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c Tue May 24 09:02:05 2011 +0100
> +++ b/tools/libxc/xc_domain_restore.c Tue May 24 09:10:54 2011 +0100
> @@ -1133,23 +1133,19 @@ int xc_domain_restore(xc_interface *xch,
>
> int orig_io_fd_flags;
>
> - static struct restore_ctx _ctx = {
> - .live_p2m = NULL,
> - .p2m = NULL,
> - };
> - static struct restore_ctx *ctx = &_ctx;
> + struct restore_ctx _ctx;
> + struct restore_ctx *ctx = &_ctx;
> struct domain_info_context *dinfo = &ctx->dinfo;
>
> pagebuf_init(&pagebuf);
> memset(&tailbuf, 0, sizeof(tailbuf));
> tailbuf.ishvm = hvm;
>
> - /* For info only */
> - ctx->nr_pfns = 0;
> -
> if ( superpages )
> return 1;
>
> + memset(ctx, 0, sizeof(*ctx));
> +
> ctxt = xc_hypercall_buffer_alloc(xch, ctxt, sizeof(*ctxt));
>
> if ( ctxt == NULL )
> diff -r 9cf8d3826060 -r 13599c2c82d8 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c Tue May 24 09:02:05 2011 +0100
> +++ b/tools/libxc/xc_domain_save.c Tue May 24 09:10:54 2011 +0100
> @@ -958,11 +958,8 @@ int xc_domain_save(xc_interface *xch, in
> unsigned long mfn;
>
> struct outbuf ob;
> - static struct save_ctx _ctx = {
> - .live_p2m = NULL,
> - .live_m2p = NULL,
> - };
> - static struct save_ctx *ctx = &_ctx;
> + struct save_ctx _ctx;
> + struct save_ctx *ctx = &_ctx;
> struct domain_info_context *dinfo = &ctx->dinfo;
>
> int completed = 0;
> @@ -976,6 +973,8 @@ int xc_domain_save(xc_interface *xch, in
>
> outbuf_init(xch, &ob, OUTBUF_SIZE);
>
> + memset(ctx, 0, sizeof(*ctx));
> +
> /* If no explicit control parameters given, use defaults */
> max_iters = max_iters ? : DEF_MAX_ITERS;
> max_factor = max_factor ? : DEF_MAX_FACTOR;
>
>
>
next prev parent reply other threads:[~2011-05-24 15:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-23 23:05 [PATCH] libxc: reset completed flag in restore_ctx Jim Fehlig
2011-05-24 8:13 ` Ian Campbell
2011-05-24 15:12 ` Jim Fehlig [this message]
2011-05-24 17:33 ` Ian Jackson
2011-05-24 17:47 ` Jim Fehlig
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=4DDBCAEF.9030401@novell.com \
--to=jfehlig@novell.com \
--cc=Ian.Campbell@citrix.com \
--cc=Vincent.Hanquez@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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.