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

[Pavel Emelyanov]

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.

> 	...
> }
> .
>