[CRIU] [PATCH 1/2] don't assume the kernel has CONFIG_SECCOMP

[Pavel Emelyanov]

On 06/25/2015 06:18 PM, Tycho Andersen wrote:
> On Thu, Jun 25, 2015 at 06:15:43PM +0300, Pavel Emelyanov wrote:
>>
>>>> Why is this required? If criu finds seccomp mark in /proc, then shouldn't
>>>> it properly parse one?
>>>
>>> The problem is when it doesn't have Seccomp:. We won't get to 9 things
>>> parsed, even though we check for 9 things. I suppose it's not strictly
>>> necessary in the while() loop, but the check for success below
>>> requires it.
>>
>> Ah, but then this check is not about CONFIG_HAS_SECCOMP (user space library) but
>> purely about kernel. Either we meet one there or not, but we should not depend on 
>> the userspace library presence.
> 
> We're not depending on the library presence, are we? 

Well, this hunk

@@ -780,7 +785,13 @@ int parse_pid_status(pid_t pid, struct proc_status_creds *cr)
 	if (bfdopenr(&f))
 		return -1;
 
-	while (done < 9) {
+#ifdef CONFIG_HAS_SECCOMP
+#define THINGS_TO_PARSE 9
+#else
+#define THINGS_TO_PARSE 8
+#endif
+
+	while (done < THINGS_TO_PARSE) {
 		str = breadline(&f);
 		if (str == NULL)
 			break;

from patch #1 brings one :) If there's no seccomp.h header on the system the proc
parsing code starts ignoring the Seccomp: field. While the field presence doesn't
depend on it.

> The problem is
> that a /proc/pid/status entry will simply not have a line containing
> "Seccomp:" if it is kernel 3.11, but if we expect it to be there (by
> requiring 9 successful things to parse), we will always fail on a 3.11
> kernel.

Yes, but on the other hand, if we don't have seccomp.h while process is seccomp-ed
we will ignore this fact.

-- Pavel