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

[Gu Zheng]

On 2012/11/13 14:52, Pavel Emelyanov wrote:
> 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.
> 

Yes, This is a key issue that I want to discuss with you. As you said, Our work is built on 
the ptrace-seize, when we deal with a task is blocked on a flock, the kernel will unblock task
from flock and will stop it in another place in theory. To be more correct, I'll check it.
If it's true, the feather work maybe simpler and bright. Thanks for your remind! :) 

> Thanks,
> Pavel
> 
>