On Mon, 2 Mar 2009 07:37:54 -0600 "Serge E. Hallyn" <serue@xxxxxxxxxx> wrote: > Quoting Dave Hansen (dave@xxxxxxxxxxxxxxxxxx): > > > > 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@xxxxxxxxxxxxxxxxxx> > > 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? _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
