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

[Cyrill Gorcunov]

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.
	...
}