[CRIU] [PATCH 1/2] zdtm: introduced a local version of O_LARGEFILE

[Andrey Wagin]

2013/2/1 Pavel Emelyanov <xemul at parallels.com>:
> On 01/31/2013 10:21 AM, Cyrill Gorcunov wrote:
>> On Thu, Jan 31, 2013 at 06:19:58AM +0400, Pavel Emelyanov wrote:
>>>>>
>>>>> Try calling rst_file_parms afterwards.
>>>>
>>>> If only I've not missed something obvious (it's nitgh and i'm somehow
>>>> semisleep already :) it won't does the trick
>>>>
>>>> #define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | O_DIRECT | O_NOATIME)
>>>>
>>>> static int setfl(int fd, struct file * filp, unsigned long arg)
>>>> {
>>>>     ...
>>>>     spin_lock(&filp->f_lock);
>>>>     filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK);
>>>>     spin_unlock(&filp->f_lock);
>>>>
>>>> where the args is the new flags set.
>>>
>>> Can kernel change this flag at all?
>>> If can -- fix the set. If no -- we're in trouble :(
>>
>> As far as I see, on 64 bit system this flag is always set
>> by the kernel and can't be clear. Need to figure out if
>> patching the kernel will not cause any side effects.
>
> Do NOT patch the kernel for this. Let's better concentrate on finding out
> why the hell we open() the pipe at all in this case. Andrey should know
> the answer, this is his code.

It's for restoring unshared file descriptors. Look at the attached test case.
I did not know about side effects of "open", so a pipe descriptor is
reopened even if it's only one for the end of pipe.

>
>> .
>>
>
>
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-zdtm-check-unshared-descriptors-for-one-end-of-a-pip.patch
Type: application/octet-stream
Size: 2106 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130201/eaca66d7/attachment.obj>