All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Smith <danms@us.ibm.com>
To: "Serge E. Hallyn" <serue@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 12:25:08 -0800	[thread overview]
Message-ID: <87sk8t6msb.fsf@caffeine.danplanet.com> (raw)
In-Reply-To: <20100222195647.GB13135@us.ibm.com> (Serge E. Hallyn's message of "Mon\, 22 Feb 2010 13\:56\:47 -0600")

>> +	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.

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.

-- 
Dan Smith
IBM Linux Technology Center
email: danms@us.ibm.com

  reply	other threads:[~2010-02-22 20:25 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 [this message]
2010-02-22 20:57         ` Serge E. Hallyn
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=87sk8t6msb.fsf@caffeine.danplanet.com \
    --to=danms@us.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=netdev@vger.kernel.org \
    --cc=serue@us.ibm.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.