[CRIU] Question on File Locks

[Pavel Emelyanov]

On 04/02/2015 08:50 PM, Saied Kazemi wrote:
> Hi Pavel,
> 
> The "What cannot be checkpointed page" says:
> 
>     /On dump it's impossible to find out whether this lock help by one task can be used
>     by some other. Thus, CRIU doesn't dump tasks with held locks. The |--file-locks| CLI 
>     option tells CRIU to dump the lock./
>     /
>     /
> 
> I ran into this issue and had to use --file-locks to dump the container.
> 
> Is there a chance of file corruption or some undesired side-effect using --file-locks?  

Yup. Generally speaking, if some task locks a file it enters some "critical
section". If we just dump-and-kill this task we effectively leave whatever
this task was doing in an intermediate state. If we restore this task with
lock -- no problem, it will continue the critical section and complete one
the way it thinks is appropriate. But if before the restore some other process
appears that works on the same data and expects to see things in somehow
completed state -- this process will be surprised. And since we're talking
on a "generic process" the results of such surprise are unpredictable.

That said we introduced the option that says: "I do know that tasks I dump
will not leave anything that can be came upon by unwanted processes". E.g.
this is the case for containers -- external processes are not expected to
mess with container's fs and locks.

> If no, can't CRIU always assume that --file-locks is specified?

We can introduce an option --container which will imply several other options,
but so far only --file-locks come to mind. Maybe also the --tcp-establised one.

Also with --container it would be natural to address container by name,
not by the task pid :) But this addressing it project-specific and also
doesn't seem to be criu's level.

 --Pavel