[CRIU] [PATCH resend v7 00/14] net/ipv6: c/r dev/default/all conf ops

[Pavel Tikhomirov]

On 04/27/2016 04:20 PM, Pavel Emelyanov wrote:
>>> He needs more fun to be happy;)
>>   From log:
>> 19:10:43.799:     5: FAIL: netns-dev.c:264: Option
>> "/proc/sys/net/ipv6/conf/lo/mldv1_unsolicited_report_interval" changed
>> from 135188171 to 135188172 (errno = 2 (No such file or directory))
>>
>> I think in Travis environment someone or something increments(1 to 5
>> times in different runs) mldv1_unsolicited_report_interval and thus
>> breaks the test(small change in value is too suspicious). But I'm not
>> sure how to reproduce the environment locally, is there a common way?
>>
>> See the same behavior for test run with "--nocr" below, test fails
>> without c/r'ing it.
>> https://travis-ci.org/Snorch/criu/jobs/125944022
> So, does this mean there will be v8?

CONFIG_HZ can influence mldv1_unsolicited_report_interval granularity, 
for instance travis.ci has CONFIG_HZ=250 and thus 
mldv1_unsolicited_report_interval is rounded up to the nearest 
(MSEC_PER_SEC / HZ)*k which is equal to 4*k here[see kernel 
proc_dointvec_ms_jiffies > do_proc_dointvec > 
do_proc_dointvec_ms_jiffies_conv > msecs_to_jiffies].

So mldv1_unsolicited_report_interval and 
mldv2_unsolicited_report_interval can have different granularity 
depending on CONFIG_HZ.

I have question now: Do we need to restore these multicast discovery 
report intervals precisely, or can leave what we have now? - e.g. 
restoring with different HZ can slightly change intervals, need to fix 
gen_conf in test to check values just after set. Personally I think it 
is quiet safe, no one will ever mention difference in several milliseconds.

>
>> 21:00:54.226:     5: FAIL: netns-dev.c:264: Option
>> "/proc/sys/net/ipv6/conf/lo/mldv1_unsolicited_report_interval" changed
>> from 39342981 to 39342984 (errno = 2 (No such file or directory))
>>