From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
containers <containers@lists.linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 00/11] track files for checkpointability
Date: Thu, 05 Mar 2009 14:24:25 -0800 [thread overview]
Message-ID: <1236291865.22399.139.camel@nimitz> (raw)
In-Reply-To: <20090305220044.GA2819@x200.localdomain>
On Fri, 2009-03-06 at 01:00 +0300, Alexey Dobriyan wrote:
> On Thu, Mar 05, 2009 at 01:27:07PM -0800, Dave Hansen wrote:
> > > Imagine, unsupported file is opened between userspace checks
> > > for /proc/*/checkpointable and /proc/*/fdinfo/*/checkpointable
> > > and whatever, you stil have to do all the checks inside checkpoint(2).
> >
> > Alexey, we have two problems here. I completely agree that we have to
> > do complete and thorough checks of each file descriptor at
> > sys_checkpoint(). Any checks made at other times should not be trusted.
> >
> > The other side is what Ingo has been asking for. How do we *know* when
> > we are checkpointable *before* we call (and without calling)
>
> This "without calling checkpoint(2)" results in much complications
> as demonstrated.
I'll let you take that up with Ingo. :)
> task_struct and file are not like other structures because they are exposed
> in /proc.
Very true. But, we can always use the task as a proxy to say whether
any of this tasks's *resources* are uncheckpointable. Is this task's
ipc_namespace checkpointable, etc...
> For PROC_FS=n kernels, one can't even check.
Definitely. I'd be happy to make this check require PROC=y or even
DEBUGFS=y. I just want to make the mechanism usable for developers so
they're more motivated to find and fix checkpoint issues.
> You can do checkpoint(2) without actual dump. You pass, you're most
> certainly checkpointable (with inevitable race condition in mind).
OK, so you envision this as maybe calling sys_checkpoint() with a -1 fd
or something? I'm generally OK with that. If the /proc stuff is really
the sticking point here, I'd be happy to stick it at the end of the
series so we can throw it away more easily.
> With time the amount of stuff C/R won't support will approach zero,
> but the infrastructure for "checkpointable" will stay constant.
> If it's too much right now, it will be way too much in future.
What have you seen in OpenVZ? Do new things that are not checkpointable
pop up very often?
-- Dave
next prev parent reply other threads:[~2009-03-05 22:24 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-05 16:38 [RFC][PATCH 00/11] track files for checkpointability Dave Hansen
2009-03-05 16:38 ` Dave Hansen
2009-03-05 16:38 ` [RFC][PATCH 01/11] kill '_data' in cr_hdr_fd_data name Dave Hansen
2009-03-05 16:38 ` Dave Hansen
2009-03-05 16:38 ` [RFC][PATCH 02/11] breakout fdinfo sprintf() into its own function Dave Hansen
2009-03-05 16:38 ` Dave Hansen
2009-03-05 16:39 ` [RFC][PATCH 03/11] Introduce generic_file_checkpoint() Dave Hansen
2009-03-05 16:39 ` Dave Hansen
2009-03-05 16:39 ` [RFC][PATCH 04/11] actually use f_op in checkpoint code Dave Hansen
2009-03-05 16:39 ` Dave Hansen
2009-03-05 16:39 ` [RFC][PATCH 05/11] add generic checkpoint f_op to ext fses Dave Hansen
2009-03-05 16:39 ` Dave Hansen
2009-03-13 2:50 ` Oren Laadan
2009-03-13 2:50 ` Oren Laadan
2009-03-05 16:39 ` [RFC][PATCH 06/11] add checkpoint_file_generic() to /proc Dave Hansen
2009-03-05 16:39 ` Dave Hansen
2009-03-05 16:39 ` [RFC][PATCH 07/11] file c/r: expose functions to query fs support Dave Hansen
2009-03-05 16:39 ` Dave Hansen
2009-03-05 16:39 ` [RFC][PATCH 08/11] expose file checkpointability and reasoning in /proc Dave Hansen
2009-03-05 16:39 ` Dave Hansen
2009-03-05 16:39 ` [RFC][PATCH 09/11] check files for checkpointability Dave Hansen
2009-03-05 16:39 ` Dave Hansen
2009-03-09 17:38 ` Matt Helsley
2009-03-09 17:38 ` Matt Helsley
2009-03-12 19:14 ` Dave Hansen
[not found] ` <20090309173837.GC7561-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-12 19:14 ` Dave Hansen
2009-03-05 16:39 ` [RFC][PATCH 10/11] add checkpoint/restart compile helper Dave Hansen
2009-03-05 16:39 ` Dave Hansen
2009-03-05 16:39 ` [RFC][PATCH 11/11] optimize c/r check in dup_fd() Dave Hansen
2009-03-05 16:39 ` Dave Hansen
2009-03-05 17:40 ` [RFC][PATCH 00/11] track files for checkpointability Alexey Dobriyan
2009-03-05 17:40 ` Alexey Dobriyan
[not found] ` <20090305174037.GA2274-2ev+ksY9ol182hYKe6nXyg@public.gmane.org>
2009-03-05 19:16 ` Dave Hansen
2009-03-05 19:16 ` Dave Hansen
2009-03-05 21:08 ` Alexey Dobriyan
2009-03-05 21:08 ` Alexey Dobriyan
[not found] ` <20090305210840.GA2499-2ev+ksY9ol182hYKe6nXyg@public.gmane.org>
2009-03-05 21:27 ` Dave Hansen
2009-03-05 21:27 ` Dave Hansen
2009-03-05 22:00 ` Alexey Dobriyan
[not found] ` <20090305220044.GA2819-2ev+ksY9ol182hYKe6nXyg@public.gmane.org>
2009-03-05 22:24 ` Dave Hansen
2009-03-06 15:08 ` Greg Kurz
2009-03-05 22:24 ` Dave Hansen [this message]
2009-03-06 14:34 ` Serge E. Hallyn
2009-03-06 15:48 ` Dave Hansen
2009-03-06 16:23 ` Serge E. Hallyn
2009-03-06 16:23 ` Serge E. Hallyn
2009-03-06 16:46 ` Dave Hansen
2009-03-06 18:24 ` Serge E. Hallyn
2009-03-06 19:42 ` Dave Hansen
[not found] ` <20090306182451.GA6307-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-06 19:42 ` Dave Hansen
2009-03-06 18:24 ` Serge E. Hallyn
[not found] ` <20090306162337.GA3040-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-06 16:46 ` Dave Hansen
2009-03-13 3:05 ` Oren Laadan
[not found] ` <20090306143425.GA31250-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-06 15:48 ` Dave Hansen
2009-03-13 3:05 ` Oren Laadan
2009-03-06 14:34 ` Serge E. Hallyn
2009-03-06 15:08 ` Greg Kurz
2009-03-06 15:35 ` Serge E. Hallyn
[not found] ` <20090306153549.GA898-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-06 17:36 ` Cedric Le Goater
2009-03-06 17:36 ` Cedric Le Goater
2009-03-06 18:30 ` Serge E. Hallyn
[not found] ` <20090306183055.GA6729-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-11 7:51 ` Cedric Le Goater
2009-03-11 7:51 ` Cedric Le Goater
[not found] ` <49B76D91.1020807-GANU6spQydw@public.gmane.org>
2009-03-12 15:30 ` Serge E. Hallyn
2009-03-12 15:30 ` Serge E. Hallyn
2009-03-13 6:36 ` Ensuring c/r maintainability (WAS Re: [RFC][PATCH 00/11] track files for checkpointability) Matt Helsley
2009-03-13 17:53 ` Serge E. Hallyn
[not found] ` <49B15F35.2010909-GANU6spQydw@public.gmane.org>
2009-03-06 18:30 ` [RFC][PATCH 00/11] track files for checkpointability Serge E. Hallyn
2009-03-06 15:35 ` Serge E. Hallyn
2009-03-05 22:00 ` Alexey Dobriyan
2009-03-05 19:44 ` Dave Hansen
2009-03-05 19:44 ` Dave Hansen
2009-03-05 18:13 ` Serge E. Hallyn
[not found] ` <20090305181325.GA10666-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-05 18:16 ` Dave Hansen
2009-03-05 18:16 ` Dave Hansen
2009-03-05 18:13 ` Serge E. Hallyn
2009-03-10 15:57 ` Nathan Lynch
2009-03-10 16:00 ` Nathan Lynch
2009-03-10 16:23 ` Serge E. Hallyn
[not found] ` <20090310110000.24893e0c-4v5LP+xe+1byhTdZtsIeww@public.gmane.org>
2009-03-10 16:23 ` Serge E. Hallyn
[not found] ` <20090310105702.43eb1402-4v5LP+xe+1byhTdZtsIeww@public.gmane.org>
2009-03-10 16:00 ` Nathan Lynch
2009-03-10 16:20 ` Serge E. Hallyn
2009-03-10 16:22 ` Dave Hansen
2009-03-10 16:20 ` Serge E. Hallyn
[not found] ` <20090310162026.GA9354-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-10 17:23 ` Nathan Lynch
2009-03-10 17:23 ` Nathan Lynch
2009-03-10 17:45 ` Serge E. Hallyn
[not found] ` <20090310174517.GA12101-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-10 17:47 ` Dave Hansen
2009-03-10 17:47 ` Dave Hansen
2009-03-10 22:54 ` what is CONFIG_VZ_GENCALLS Zhaohui Wang
[not found] ` <20090310122320.313491ce-4v5LP+xe+1byhTdZtsIeww@public.gmane.org>
2009-03-10 17:45 ` [RFC][PATCH 00/11] track files for checkpointability Serge E. Hallyn
2009-03-10 16:22 ` Dave Hansen
2009-03-10 15:57 ` Nathan Lynch
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=1236291865.22399.139.camel@nimitz \
--to=dave@linux.vnet.ibm.com \
--cc=adobriyan@gmail.com \
--cc=containers@lists.linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.