From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Cedric Le Goater <legoater@free.fr>
Cc: Greg Kurz <gkurz@fr.ibm.com>,
containers <containers@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Christoph Hellwig <hch@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [RFC][PATCH 00/11] track files for checkpointability
Date: Fri, 6 Mar 2009 12:30:55 -0600 [thread overview]
Message-ID: <20090306183055.GA6729@us.ibm.com> (raw)
In-Reply-To: <49B15F35.2010909@free.fr>
Quoting Cedric Le Goater (legoater@free.fr):
> Serge E. Hallyn wrote:
> > Quoting Greg Kurz (gkurz@fr.ibm.com):
> >> 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.
> >>>
> >>> task_struct and file are not like other structures because they are exposed
> >>> in /proc. For PROC_FS=n kernels, one can't even check.
> >>>
> >>> You can do checkpoint(2) without actual dump. You pass, you're most
> >>> certainly checkpointable (with inevitable race condition in mind).
> >>>
> >> Ahhh thank you very much Alexey ! I wanted to explain this to Dave a few
> >> monthes ago but I failed... probably because of my poor English skills.
> >>
> >> https://lists.linux-foundation.org/pipermail/containers/2008-October/013549.html
> >>
> >> Why would we add checking all over the place when it MUST be done on the
> >> sys_checkpoint() path ? The checkpoint(2) dry-run is definitely the way
> >> to go.
> >
> > I'm sure Dave understood that this was possible :)
> >
> > But what you and Alexey are proposing does not and cannot fullfill
> > Ingo's requirement.
>
> And if Ingo's requirement is fulfilled, would any C/R patchset be acceptable ?
Yup, no matter how hideous :) Ok not really.
But the point was that it wasn't Dave not understanding Alexey's
suggestion, but Greg not understanding Ingo's. If you think Ingo's
goal isn't worthwhile or achievable, then argue that (as I am), don't
keep elaborating on something we all agree will be needed (Alexey's
suggestion or some other way of doing a true may-be-checkpointed test).
-serge
next prev parent reply other threads:[~2009-03-06 18:38 UTC|newest]
Thread overview: 47+ 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 ` [RFC][PATCH 01/11] kill '_data' in cr_hdr_fd_data name Dave Hansen
2009-03-05 16:38 ` [RFC][PATCH 02/11] breakout fdinfo sprintf() into its own function Dave Hansen
2009-03-05 16:39 ` [RFC][PATCH 03/11] Introduce generic_file_checkpoint() 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 ` [RFC][PATCH 05/11] add generic checkpoint f_op to ext fses Dave Hansen
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 ` [RFC][PATCH 07/11] file c/r: expose functions to query fs support 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 ` [RFC][PATCH 09/11] check files for checkpointability Dave Hansen
2009-03-09 17:38 ` Matt Helsley
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 ` [RFC][PATCH 11/11] optimize c/r check in dup_fd() Dave Hansen
2009-03-05 17:40 ` [RFC][PATCH 00/11] track files for checkpointability Alexey Dobriyan
2009-03-05 19:16 ` Dave Hansen
2009-03-05 21:08 ` Alexey Dobriyan
2009-03-05 21:27 ` Dave Hansen
2009-03-05 22:00 ` Alexey Dobriyan
2009-03-05 22:24 ` Dave Hansen
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:46 ` Dave Hansen
2009-03-06 18:24 ` Serge E. Hallyn
2009-03-06 19:42 ` Dave Hansen
2009-03-13 3:05 ` Oren Laadan
2009-03-06 15:08 ` Greg Kurz
2009-03-06 15:35 ` Serge E. Hallyn
2009-03-06 17:36 ` Cedric Le Goater
2009-03-06 18:30 ` Serge E. Hallyn [this message]
2009-03-11 7:51 ` Cedric Le Goater
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
2009-03-05 19:44 ` [RFC][PATCH 00/11] track files for checkpointability Dave Hansen
2009-03-05 18:13 ` Serge E. Hallyn
2009-03-05 18:16 ` Dave Hansen
2009-03-10 15:57 ` Nathan Lynch
2009-03-10 16:00 ` Nathan Lynch
2009-03-10 16:23 ` Serge E. Hallyn
2009-03-10 16:20 ` Serge E. Hallyn
2009-03-10 17:23 ` Nathan Lynch
2009-03-10 17:45 ` Serge E. Hallyn
2009-03-10 17:47 ` Dave Hansen
2009-03-10 16:22 ` Dave Hansen
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=20090306183055.GA6729@us.ibm.com \
--to=serue@us.ibm.com \
--cc=adobriyan@gmail.com \
--cc=containers@lists.linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=gkurz@fr.ibm.com \
--cc=hch@infradead.org \
--cc=legoater@free.fr \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox