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".
next prev 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