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

[Pavel Emelyanov]

On 01/31/2013 01:31 AM, Cyrill Gorcunov wrote:
> On Thu, Jan 31, 2013 at 01:16:43AM +0400, Pavel Emelyanov wrote:
>> On 01/30/2013 03:53 PM, Cyrill Gorcunov wrote:
>>> On Wed, Jan 30, 2013 at 03:35:14PM +0400, Pavel Emelyanov wrote:
>>>> On 01/30/2013 10:32 AM, Alexander Kartashov wrote:
>>>>> On 01/30/2013 03:13 AM, Pavel Emelyanov wrote:
>>>>>> In what header?
>>>>> It's the header /usr/include/x86_64-linux-gnu/bits/fcntl.h in my distro.
>>>>>> OK, so zdtm test opens file with O_LARGEFILE flag, doesn't it?
>>>>>
>>>>> The test static/file_fown tests C/R of pipes. Descriptors of pipe ends
>>>>> are created by the kernel without the flag O_LARGEFILE. crtools dumps
>>>>> everything correctly.
>>>>>
>>>>> When a pipe is restored one of its ends is reopened using the function
>>>>> open() that adds the flag O_LARGEFILE specifically its kernel version.
>>>>> So the test detects that file flags on a pipe descriptor changed during
>>>>> the C/R cycle and reports a error.
>>>>
>>>> It's a bug in crtools. O_LARGEFILE shouldn't appear on an FD.
>>>
>>> As far as I see we indeed receive pipe end as
>>>
>>> static int recv_pipe_fd(struct pipe_info *pi)
>>> {
>>> 	...
>>> 	tmp = recv_fd(fd);
>>> 	if (tmp < 0) {
>>> 		pr_err("Can't get fd %d\n", tmp);
>>> 		return -1;
>>> 	}
>>> 	close(fd);
>>>
>>> 	snprintf(path, sizeof(path), "/proc/self/fd/%d", tmp);
>>> 	fd = open(path, pi->pe->flags);
>>>
>>> 	here the kernel will add O_LARGEFILE if bits-per-long != 32,
>>> 	ie on x86-64, this is side effect of open system call, i'm
>>> 	not sure how can we escape this.
>>
>> 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 :(

> 	Cyrill
> .
>