Ingo Molnar wrote: > * Dave Hansen <dave@xxxxxxxxxxxxxxxxxx> wrote: > >> On Thu, 2008-10-09 at 15:44 +0200, Ingo Molnar wrote: >>> there might be races as well, especially with proxy state - and >>> current->flags updates are not serialized. >>> >>> So maybe it should be a completely separate flag after all? Stick it >>> into the end of task_struct perhaps. >> What do you mean by proxy state? nsproxy? > > it's a concept: one task installing some state into another task (which > state must be restored after a checkpoint event), while that other task > is running. Such as a pi-futex state for example. > > So a task can acquire state not just by its own doing, but via some > other task too. thinking aloud, hmm, that's rather complex, because we have to take into account the kernel stack, no ? This is what Andrey was trying to solve in his patchset back in September : http://lkml.org/lkml/2008/9/3/96 the restart phase simulates a clone and switch_to to (not) restore the kernel stack. right ? the self checkpoint and self restore syscalls, like Oren is proposing, are simpler but they require the process cooperation to be triggered. we could image doing that in a special signal handler which would allow us to jump in the right task context. I don't have any preference but looking at the code of the different patchsets there are some tricky areas and I'm wondering which path is easier, safer, and portable. C. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
