Linux Container Development
 help / color / mirror / Atom feed
From: Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
To: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: Linux Containers
	<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
	Alexey Dobriyan
	<adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 1/1] cr: define CHECKPOINT_SUBTREE flag and sysctl
Date: Fri, 24 Apr 2009 19:07:11 -0500	[thread overview]
Message-ID: <m3vdotk34g.fsf@pobox.com> (raw)
In-Reply-To: <20090424210608.GA16973-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> (Serge E. Hallyn's message of "Fri\, 24 Apr 2009 16\:06\:08 -0500")

"Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
> Define a CHECKPOINT_SUBTREE flag for sys_checkpoint() which
> says it's ok if the the checkpointed set of tasks are not
> a fully isolated container without leaks.
>
> Define a sysctl 'ckpt_subtree_allowed' which determines
> whether subtree checkpoints are ok.  If that sysctl,
> ckpt_subtree_allowed, is 0, then the CHECKPOINT_SUBTREE flag
> may not be used.  Also, if that sysctl is 0, then both
> sys_checkpoint() and sys_restart() always require
> CAP_SYS_ADMIN.

Whether subtree checkpoint is allowed and whether non-admin checkpoint
is allowed are independent constraints, no?  Should this really be a
single flag?


> +static int check_obj_isolated(struct cr_ctx *ctx, struct cr_objref *ref)
> +{
> +	struct uts_namespace *utsns;
> +	struct ipc_namespace *ipcns;
> +	struct file *file;
> +	struct mm_struct *mm;
> +	unsigned long cnt, cnt2;
> +	int ret = 1;
> +
> +	/* note - one might think it worthwhile to put the ns
> +	 * ones under #ifdefs for the CONFIG_X_NS, but instead
> +	 * it CONFIG_CHECKPOINT should depend on all of those
> +	 */
> +	/* note2: the objhash has taken a reference, so we account
> +	 * for that */
> +
> +	cnt = ref->users + 1;
> +	switch (ref->type) {
> +	case CR_OBJ_UTSNS:
> +		utsns = ref->ptr;
> +		cnt2 = (unsigned long) atomic_read(&utsns->kref.refcount);
> +		if (cnt != cnt2) {
> +			cr_debug("uts namespace leak\n");

I'm struggling to understand what guarantee a check such as this is
supposed to be making.  I see that it will catch *some* undesirable
cases.  But "current refcount equals old refcount" does not imply that
"refcount has not changed in the meantime".

  parent reply	other threads:[~2009-04-25  0:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-24 21:06 [PATCH 1/1] cr: define CHECKPOINT_SUBTREE flag and sysctl Serge E. Hallyn
     [not found] ` <20090424210608.GA16973-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-04-25  0:07   ` Nathan Lynch [this message]
     [not found]     ` <m3vdotk34g.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2009-04-25  2:45       ` Serge E. Hallyn
     [not found]         ` <20090425024515.GA4534-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
2009-04-25  2:51           ` Serge E. Hallyn
     [not found]             ` <20090425025154.GA4596-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
2009-04-27  4:37               ` Serge E. Hallyn
2009-04-27 17:14           ` Nathan Lynch
     [not found]             ` <m3y6tmt3wb.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2009-04-27 18:07               ` Serge E. Hallyn
     [not found]                 ` <20090427180717.GA28476-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-04-27 18:37                   ` Nathan Lynch
2009-04-27 19:09                   ` Alexey Dobriyan
     [not found]                     ` <20090427190947.GA14148-2ev+ksY9ol182hYKe6nXyg@public.gmane.org>
2009-04-27 19:30                       ` Serge E. Hallyn
2009-04-27 20:11                   ` Oren Laadan
     [not found]                     ` <49F61181.9010809-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-04-27 20:38                       ` Serge E. Hallyn
     [not found]                         ` <20090427203858.GA32290-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-04-27 22:13                           ` Oren Laadan
2009-04-25  8:39   ` Matt Helsley
     [not found]     ` <20090425083908.GA2767-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-04-30 14:57       ` Serge E. Hallyn
     [not found]         ` <20090430145735.GA19684-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-04-30 15:14           ` Oren Laadan
     [not found]             ` <49F9C044.8040907-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-04-30 15:26               ` Serge E. Hallyn
     [not found]                 ` <20090430152615.GC19684-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-04-30 15:40                   ` Oren Laadan
2009-04-27 20:12   ` Oren Laadan

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=m3vdotk34g.fsf@pobox.com \
    --to=ntl-e+axbwqsrlaavxtiumwx3w@public.gmane.org \
    --cc=adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=serue-r/Jw6+rmf7HQT0dZR+AlfA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox