Messages in this thread | | | Subject | Re: [RFC][PATCH 1/2] Track in-kernel when we expect checkpoint/restart to work | From | Greg Kurz <> | Date | Fri, 10 Oct 2008 10:47:01 +0200 |
| |
On Fri, 2008-10-10 at 10:37 +0200, Daniel Lezcano wrote: > I think implementing the reverse operation will be a nightmare, IMHO it > is safe to say we deny checkpointing for the process life-cycle either > if the created resource was destroyed before we initiate the checkpoint. > > For example, you create a socket, the process becomes uncheckpointable, > you close (via sys_close) the socket, you have to track this close to be > related to the socket which made the process uncheckpointable in order > to make the operation reversible. > > Let's imagine you implement this reverse operation anyway, you have a > process which creates a TCP connection, writes data and close the socket > (so you are again checkpointable), but in the namespace there is the > orphan socket which is not checkpointable yet and you missed this case.
That's exactly what I wanted to read... Tracking only is inherently flawed. The valid way IMHO implies checks at checkpoint time.
-- Gregory Kurz gkurz@fr.ibm.com Software Engineer @ IBM/Meiosys http://www.ibm.com Tel +33 (0)534 638 479 Fax +33 (0)561 400 420
"Anarchy is about taking complete responsibility for yourself." Alan Moore.
| |