Quoting Dave Hansen ([email protected]): > > 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 <[email protected]>
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? -serge _______________________________________________ Containers mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
