All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Dan Smith <danms@us.ibm.com>
Cc: containers@lists.osdl.org, netdev@vger.kernel.org
Subject: Re: [PATCH 3/5] Add checkpoint support for veth devices (v2)
Date: Mon, 22 Feb 2010 14:57:38 -0600	[thread overview]
Message-ID: <20100222205738.GA18038@us.ibm.com> (raw)
In-Reply-To: <87sk8t6msb.fsf@caffeine.danplanet.com>

Quoting Dan Smith (danms@us.ibm.com):
> >> +	else if (!ckpt_obj_lookup(ctx, peer->nd_net, CKPT_OBJ_NET_NS)) {
> >> +		ret = -EINVAL;
> >> +		ckpt_err(ctx, ret,
> >> +			 "Peer %s of %s not in checkpointed namespaces\n",
> >> +			 peer->name, dev->name);
> 
> SH> I'm not sure this check does what you think it does: note that
> SH> ckpt_netdev_base(), defined in the previous patch, and called
> SH> higher up in this function, is going to checkpoint peer->nd_net.
> SH> :)
> 
> Actually, no, ckpt_netdev_base() can't checkpoint peer->nd_net because
> it's device-agnostic and has no knowledge of dev->peer.

Oh, ok.

> The idea here was that we checkpoint a netns when we arrive at it via
> nsproxy.  Doing that, we checkpoint the devices within.  We encounter
> a veth device, which has a peer, so we decide if:
> 
>  1. We won't arrive at the peer later because it is in the init
>     namespace, so we checkpoint it now.
>  2. We will arrive at it later because the peer's netns is in the list
>     we've already collected, so checkpoint the peer with its namespace
>  3. Neither are true and we won't arrive at it later and therefore we
>     can't allow checkpoint to continue
> 
> #2 depends on the collect process having put all the task's netns' in
>  the hash ahead of time.

Right, that was what I was originally starting to hunt down when I
thought I saw ckpt_netdev_base() checkpointing peer's netns.

So do you actually know that the peer's netns will have been
checkpointed?  I'm a little fuzzy about where netns and netdevs
are checkpointed.  If you have two private netns's in a container,
with a veth connecting them, and you checkpoint a task in netns 1,
will you fail bc netns 2 hasn't been checkpointed yet bc no task in
it has been checkpointed yet?

-serge

  reply	other threads:[~2010-02-22 20:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-16 16:03 Network device and namespace checkpoint/restart (v3) Dan Smith
2010-02-16 16:03 ` [PATCH 1/5] Add checkpoint and collect hooks to net_device_ops Dan Smith
2010-02-16 16:03 ` [PATCH 2/5] C/R: Basic support for network namespaces and devices (v4) Dan Smith
     [not found]   ` <20100222194523.GA13135@us.ibm.com>
2010-02-23 16:35     ` Dan Smith
2010-02-23 16:47       ` Serge E. Hallyn
2010-02-23 17:27         ` Dan Smith
2010-02-23 18:49           ` Serge E. Hallyn
2010-02-16 16:03 ` [PATCH 3/5] Add checkpoint support for veth devices (v2) Dan Smith
     [not found]   ` <1266336187-19105-4-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-02-22 19:56     ` Serge E. Hallyn
2010-02-22 20:25       ` Dan Smith
2010-02-22 20:57         ` Serge E. Hallyn [this message]
2010-02-22 21:01           ` Dan Smith
2010-02-16 16:03 ` [PATCH 4/5] Add loopback checkpoint support Dan Smith
2010-02-16 16:09   ` Eric Dumazet
2010-02-16 16:13     ` Dan Smith
2010-02-16 16:03 ` [PATCH 5/5] Add a checkpoint handler to the 'sit' device Dan Smith

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=20100222205738.GA18038@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=danms@us.ibm.com \
    --cc=netdev@vger.kernel.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.