xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	ian.jackson@eu.citrix.com, wei.liu2@citrix.com,
	xen-devel@lists.xen.org
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	Jim Fehlig <jfehlig@suse.com>,
	Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [PATCH for-4.6] libxl: clear O_NONBLOCK|O_NDELAY on migration fd and reinstate afterwards
Date: Fri, 11 Sep 2015 14:44:01 +0100	[thread overview]
Message-ID: <55F2DAA1.1050902@citrix.com> (raw)
In-Reply-To: <1441968171-15844-1-git-send-email-ian.campbell@citrix.com>

On 11/09/15 11:42, Ian Campbell wrote:
> The fd passed to us by libvirt for both save and restore has at least
> O_NONBLOCK set, which libxl does not expect and therefore fails to
> handle any EAGAIN which might arise.
>
> This has been observed with migration v2, but if v1 used to work I
> think that would be just be by luck and/or coincidence.
>
> Unix convention (and the principal of least surprise) is usually to
> ensure that an fd has no "strange" properties, such as being
> non-blocking, when handing it to another component.
>
> However for the convenience of the application arrange instead for
> libxl to clear any unexpected flags on the file descriptors it is
> given for save or restore and restore them to their original state at
> the end. O_NDELAY could be similarly problematic so clear that as
> well as O_NONBLOCK.
>
> To do this introduce a pair of new helper functions one to modify+save
> the flags and another to restore them and call them in the appropriate
> places.
>
> The migration v1 code appeared to do some things with O_NONBLOCK in
> the checkpoint case. Migration v2 doesn't seem to do so, and in any
> case I wouldn't expect it to be relying on libvirt's setting of
> O_NONBLOCK when xl doesn't use that flag.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jim Fehlig <jfehlig@suse.com>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> Cc: Yang Hongyang <yanghy@cn.fujitsu.com>
> ---
> For 4.6: This fixes migration with libvirt, which I think is worth
> doing before the release.
>
> For backports: Once "ts-xen-install: Rewrite /etc/hosts to comment out
> 127.0.1.1 entry" passes through osstest's pretest gate and has run on
> some of the older branches we should then know if this is necessary
> for migration v1. Or we could backport it regardless.

I don't believe any special consideration is needed for the legacy 
conversion case, as all other fds used there are created by components 
we control.

> ---
>   tools/libxl/libxl.c          | 65 ++++++++++++++++++++++++++++++++++++++++++++
>   tools/libxl/libxl_create.c   | 23 +++++++++++++++-
>   tools/libxl/libxl_internal.h | 13 +++++++++
>   3 files changed, 100 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 4f2eb24..d6efdd8 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -952,6 +952,12 @@ static void domain_suspend_cb(libxl__egc *egc,
>                                 libxl__domain_suspend_state *dss, int rc)
>   {
>       STATE_AO_GC(dss->ao);
> +    int flrc;
> +
> +    flrc = libxl__fd_flags_restore(gc, dss->fd, dss->fdfl);
> +    /* If suspend has failed already then report that error not this one. */
> +    if (flrc && !rc) rc = flrc;
> +
>       libxl__ao_complete(egc,ao,rc);
>   
>   }
> @@ -980,6 +986,11 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
>       dss->live = flags & LIBXL_SUSPEND_LIVE;
>       dss->debug = flags & LIBXL_SUSPEND_DEBUG;
>   
> +    rc = libxl__fd_flags_modify_save(gc, dss->fd,
> +                                     ~(O_NONBLOCK|O_NDELAY), 0,
> +                                     &dss->fdfl);
> +    if (rc < 0) goto out_err;
> +
>       libxl__domain_save(egc, dss);
>       return AO_INPROGRESS;
>   
> @@ -6507,6 +6518,60 @@ int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec)
>   int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock)
>     { return fd_set_flags(ctx,fd, F_GETFL,F_SETFL,"FL", O_NONBLOCK, nonblock); }
>   
> +int libxl__fd_flags_modify_save(libxl__gc *gc, int fd,
> +                                int mask, int val, int *r_oldflags)
> +{
> +    int rc, ret, fdfl;
> +
> +    fdfl = fcntl(fd, F_GETFL);
> +    if (fdfl < 0) {
> +        LOGE(ERROR, "failed to fcntl.F_GETFL for fd %d", fd);
> +        rc = ERROR_FAIL;
> +        goto out_err;
> +    }
> +
> +    LOG(DEBUG, "fnctl F_GETFL flags for fd %d are %x", fd, fdfl);

%#x to distinguish decimal and hex numbers in the same message (and 
other debug messages)

~Andrew

  parent reply	other threads:[~2015-09-11 13:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-11 10:42 [PATCH for-4.6] libxl: clear O_NONBLOCK|O_NDELAY on migration fd and reinstate afterwards Ian Campbell
2015-09-11 10:50 ` Ian Jackson
2015-09-11 12:56   ` Wei Liu
2015-09-11 14:11     ` Ian Campbell
2015-09-11 13:44 ` Andrew Cooper [this message]
2015-09-11 14:13   ` Ian Campbell

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=55F2DAA1.1050902@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jfehlig@suse.com \
    --cc=rshriram@cs.ubc.ca \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yanghy@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).