All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Sukadev Bhattiprolu
	<sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: user-cr: Extra unshare() calls ?
Date: Fri, 12 Mar 2010 08:44:11 -0600	[thread overview]
Message-ID: <20100312144411.GA9783@us.ibm.com> (raw)
In-Reply-To: <20100312015823.GB6444-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

Quoting Sukadev Bhattiprolu (sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> Sukadev Bhattiprolu [sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org] wrote:
> | Serge E. Hallyn [serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org] wrote:
> | | Quoting Sukadev Bhattiprolu (sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> | | > 
> | | > Came across this while testing LXC.
> | | > 
> | | > 
> | | > 1. Does ckpt_remount_proc() need to unshare() ? Or can we have the
> | | >    clone() that calls __ckpt_coordinator() clone with CLONE_NEWNS|CLONE_FS
> | | >    instead ?
> | | > 
> | | >    The problem with the unshare() in ckpt_remount_proc() is that it
> | | >    creates an extra level in cgroup hierarchy (see below) after restart.
> | | >    So applications expecting the cgroup hierarchy before chckpoint will
> | | >    be surprised.
> | | > 
> | | > 2. When --mount-pty (or --mntns) is specified, do we need to unshare() 
> | | >    in the parent process ? Considering only the full-container restart
> | | >    for now (ignore self-restart and subtree restart), can we just
> | | >    specify (CLONE_NEWNS|CLONE_FS) at the time of creating the first
> | | >    restarted process ?
> | | 
> | | And then move remounting of devpts into ckpt_remount_proc() called
> | | from __ckpt_coordinator() as well?
> | 
> | Yes, I missed that in the hack.
> 
> Here is a more involved fix, but not sure if there is a more efficient
> way to solve.

I don't know what you mean by more efficient - this looks good to me.
(Apart from probably also pulling the self-restart stuff off into a helper)

-serge

      parent reply	other threads:[~2010-03-12 14:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-08 20:13 user-cr: Extra unshare() calls ? Sukadev Bhattiprolu
     [not found] ` <20100308201338.GA16446-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-03-08 20:58   ` Serge E. Hallyn
     [not found]     ` <20100308205851.GB21490-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-03-08 21:11       ` Sukadev Bhattiprolu
     [not found]         ` <20100308211135.GB14607-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-03-12  1:58           ` Sukadev Bhattiprolu
     [not found]             ` <20100312015823.GB6444-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-03-12 14:44               ` Serge E. Hallyn [this message]

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=20100312144411.GA9783@us.ibm.com \
    --to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.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.