Re: [RFC][PATCH 1/2] Track in-kernel when we expectcheckpoint/restart to work

[Greg Kurz]

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@xxxxxxxxxx
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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/