Dave Hansen wrote: > On Mon, 2009-03-02 at 11:44 -0600, Serge E. Hallyn wrote: >> Quoting Dave Hansen ([email protected]): >>> On Mon, 2009-03-02 at 11:22 -0600, Nathan Lynch wrote: >>>> No.. I mean what if a process 1234 does >>>> >>>> f = fopen("/proc/1234/stat", "r"); >>>> >>>> and is then checkpointed. Can that path be resolved during restart, >>>> before pid 1234 is alive? >>> Heh, that's a good one. >>> >>> It does mean that we can't do restore like this: >>> >>> for_each_cr_task() >>> restore_task_struct() >>> restore_files() >>> ... >>> >>> We have to do: >>> >>> for_each_cr_task() >>> restore_task_struct() >>> for_each_cr_task() >>> restore_files() >>> >> Which is what we actually do, right? > > OK, I have a really evil one. > > What if task 1234 does: > > open(O_RDONLY, "/proc/5678/fdinfo/44"); > > and task 5678 does: > > open(O_RDONLY, "/proc/5678/fdinfo/55"); > > There is no right order. > > The only right way I can think to do it is that we have to loop on the > restore and defer files that we can't seem to find right now, hoping > that they'll show up as the restore progresses.
or the restore algorithm should support recursion. for example, epoll, attached 'struct files' to af_unix socket, pipes (2 ends), fifos (idem), connected socket (you need the listening end), etc. C. > Basically: > > for_each_cr_task() > deferred_files = restore_files() > retry: > making_progress = 0 > for_each(deferred_file) > restore(deferred_file) > if (making_progress) > goto retry; _______________________________________________ Containers mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
