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