Messages in this thread | | | Date | Mon, 2 Mar 2009 09:59:17 -0600 | From | Nathan Lynch <> | Subject | Re: [RFC][PATCH 8/8] check files for checkpointability |
| |
On Mon, 2 Mar 2009 07:37:54 -0600 "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> Quoting Dave Hansen (dave@linux.vnet.ibm.com): > > > > Introduce a files_struct counter to indicate whether a particular > > file_struct has ever contained a file which can not be > > checkpointed. This flag is a one-way trip; once it is set, it may > > not be unset. > > > > We assume at allocation that a new files_struct is clean and may > > be checkpointed. However, as soon as it has had its files filled > > from its parent's, we check it for real in __scan_files_for_cr(). > > At that point, we mark it if it contained any uncheckpointable > > files. > > > > We also check each 'struct file' when it is installed in a fd > > slot. This way, if anyone open()s or managed to dup() an > > unsuppored file, we can catch it. > > > > Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com> > > So on a practical note, Ingo's scheme appears to be paying off. In > order for any program's files_struct to be checkpointable right now, > it must be statically compiled, else ld.so (I assume) looks up > /proc/$$/status. So since proc is not checkpointable, the result > is irreversibly non-checkpointable. > > So... does it make sense to mark proc as checkpointable? Do we > reasonably assume that the same procfile will be available at > restart?
With respect to /proc/$x/* where $x is the pid the restarted task wants, is that not a chicken-and-egg problem?
| |