[CRIU] [PATCH 3/3] restore: Add support to flock&posix file locks' restore

[Pavel Emelyanov]

On 11/13/2012 07:27 AM, Gu Zheng wrote:
> On 2012/11/9 1:51, Pavel Emelyanov wrote:
>>> @@ -13,3 +16,77 @@ int dump_one_file_lock(FileLockEntry *fe, const struct cr_fdset *fdset)
> ......
>>> +		} else if (fe->type & F_RDLCK) {
>>> +			cmd |= LOCK_SH;
>>> +		} else if (fe->type & F_WRLCK) {
>>> +			cmd |= LOCK_EX;
>>> +		} else if (fe->type & F_UNLCK) {
>>> +			cmd |= LOCK_UN;
>>> +		} else {
>>> +			pr_err("Unknow flock type!\n");
>>> +			goto err;
>>> +		}
>>> +
>>> +		ret = flock(fe->fd, cmd);
>>
>> I believe it's not that simple. What if your app tried to lock a file and
>> hung on it since some other one was holding it. On restore time you will
>> either dead-lock here, since the lock would be busy by another restored
>> task or you will screw the locking up by locking the lock with wrong task.
> 
> Yes, the real situation is complex as you said, this one only can handle the simplest situation. 
> I'll send a full-scale one later, thanks! 

One thing to note. If I'm not mistaken, if a task is blocked on a flock and
you try to ptrace-seize one, the kernel will unblock task from flock and will
stop it in another place. Thus, the information about "this task is blocked
on a lock" should not be in the /proc/locks file. If this is true, the situation
becomes a little bit simpler.

Thanks,
Pavel