[CRIU] ✗ travis-ci: failure for Per-thread seccomp support, v3

[Cyrill Gorcunov]

On Thu, Apr 26, 2018 at 04:14:16PM -0700, Andrei Vagin wrote:
> ================ Run zdtm/static/seccomp_filter_threads in uns =================
> Start test
> Test is SUID
> ./seccomp_filter_threads --pidfile=seccomp_filter_threads.pid --outfile=seccomp_filter_threads.out
> Run criu dump
> Run criu restore
> Send the 15 signal to  240
> Wait for zdtm/static/seccomp_filter_threads(240) to die for 0.100000
> ######### Test zdtm/static/seccomp_filter_threads FAIL at result check #########
> Test output: ================================
> __NR_ptrace filtered inside a sole thread 7
> Waiting thread 0
> __NR_mincore filtered inside a sole thread 9
> __NR_prctl filtered inside a sole thread 8
> Triggering 0 __NR_ptrace thread 7
> Triggering 2 __NR_mincore thread 9
> Triggering 1 __NR_prctl thread 8
> Waiting thread 1
> Waiting thread 2
> 21:30:42.531:     5: ERR: seccomp_filter_threads.c:50: fopen failed (errno = 13 (Permission denied))
> 21:30:42.531:     5: FAIL: seccomp_filter_threads.c:201: seccomp mode mismatch -1 (errno = 13 (Permission denied))

int get_seccomp_mode(pid_t pid)
{
	FILE *f;
	char buf[PATH_MAX];

	sprintf(buf, "/proc/%d/status", pid);
	f = fopen(buf, "r+");
	if (!f) {
-->		pr_perror("fopen failed");
		return -1;
	}

	while (NULL != fgets(buf, sizeof(buf), f)) {
		int mode;

		if (sscanf(buf, "Seccomp:\t%d", &mode) != 1)
			continue;

		fclose(f);
		return mode;
	}
	fclose(f);

	return -1;
}

I suspect it's is due to "r+" mode in f = fopen(buf, "r+");. It didn't trigger on
my machine, neither in travis tests I ran. Andrew, is there simple way to rerun
this series with plain read-only (ie f = fopen(buf, "r");) without resending
the whole series?