daily CVS update output
Updating src tree: P src/lib/libm/src/e_atan2.c P src/share/dict/propernames P src/sys/arch/atari/atari/bus.c P src/sys/dev/sdmmc/if_bwfm_sdio.c P src/sys/dev/wscons/mra.c P src/sys/netinet/tcp_output.c P src/sys/netipsec/ipsec_mbuf.c P src/sys/netipsec/xform_ipcomp.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 50487720 Mar 11 03:04 ls-lRA.gz
Re: ATF X86 race with Debug Registers
Kamil Rytarowski wrote: > Sometimes we catch a bug with Debug Registers in the ptrace(2) tests: > > NetBSD/amd64 > http://releng.netbsd.org/b5reports/amd64/2018/2018.03.06.11.21.31/test.html#lib_libc_sys_t_ptrace_wait6_dbregs_dr3_trap_variable_readwrite_write_2bytes > > NetBSD/i386 > http://releng.netbsd.org/b5reports/i386/2017/2017.12.06.17.54.58/test.html#lib_libc_sys_t_ptrace_wait3_dbregs_dr2_trap_variable_readwrite_read_2bytes > > I was trying to reproduce this locally on a real hardware and in qemu > (softemu), including concurrent execution, but after merely 100M > attempts to reproduce the test-case, I've not encountered a single failure. > > Are there some special properties of these releng machines? qemu+kvm? Nothing special about it AFAIK, it's just qemu from pkgsrc running on babylon5.netbsd.org, a dual Xeon L5630, under NetBSD 7.1_STABLE. Typical load is 6-8 qemu processes and a niced -j 16 build. There's no kvm - that's only supported under Linux. If you look at the test.log file corresponding to the test.html, you can find the qemu version and full qemu command line near the top. -- Andreas Gustafsson, g...@gson.org
ATF X86 race with Debug Registers
Sometimes we catch a bug with Debug Registers in the ptrace(2) tests: NetBSD/amd64 http://releng.netbsd.org/b5reports/amd64/2018/2018.03.06.11.21.31/test.html#lib_libc_sys_t_ptrace_wait6_dbregs_dr3_trap_variable_readwrite_write_2bytes NetBSD/i386 http://releng.netbsd.org/b5reports/i386/2017/2017.12.06.17.54.58/test.html#lib_libc_sys_t_ptrace_wait3_dbregs_dr2_trap_variable_readwrite_read_2bytes I was trying to reproduce this locally on a real hardware and in qemu (softemu), including concurrent execution, but after merely 100M attempts to reproduce the test-case, I've not encountered a single failure. Are there some special properties of these releng machines? qemu+kvm? signature.asc Description: OpenPGP digital signature
Re: npf in -current amd64 (7 Mar 2018) now cannot use a "ruleset" multiple times
Hi!
It may be a fix/safeguard for a reload prolem I discussed with rmind@
and christos@ in May 2017:
To quote my analysis:
OK, I got the time to dig into it and found the cause.
Silly me has (now had) a configuration like this:
group "a" on if1 {
ruleset "blacklistd"
...
}
group default {
ruleset "blacklistd"
...
}
This leads to two group entries in the rs_dynamic list refencing the same named
dynamic ruleset.
Dynamic rulesets are matched by name in a first found basis.
rs_dynamic[0] has the ruleset reference for the default group (last entry in
the config file).
rs_dynamic[1] has the rulesat reference for the interface specific group
When reloading oldconfig->rs_dynamic[0] will be re-parented correctly to the new first
group referencing the rule name "blacklistd".
For the second new interface specific group the old first group is looked up as
parent (first match of old group list). That's when
the KASSERT fires as these dynamic rules have already been re-parented to the
new configuration.
This also explains why I see no effect of the dynamic rules. dynamic rules are
added by name and thus to the first matching entry. This is the ruleset
reference from the default group - bummer: one name but two instances.
So we have a semantic issue here - following questions arise:
1) can groups only reference unique dynamic ruleset names? This needs to be
enforced then.
2) If dynamic rulesets are to be shared then the parent notion needs to be
reworked/redesigned.
Best regards,
Frank
Looks like solition 1) was choosen for now.
Seems you just didn't trip over the underlying issue. I have not closely
followed NPF lately so I don't know the actual fix status of NPF. As in
the example above I also had the idea of re-using dynamic rulesets -
maybe this can be implemented as I still think it is useful. For now my
workaround was to have several rulesets, but this is just good enough to
work with blacklistd.
Frank
On 03/07/18 05:46, Geoff Wing wrote:
Hi,
npf previously had no issues using a "ruleset" in multiple groups, however
it now has a problem and fails with
npfctl: (re)load failed: some table has a duplicate entry?
The following is a minimal npf.conf to illustrate with it failing due to
the second ``ruleset "blacklistd"'' causing the issue:
-
$if1_if = inet4(vmx0)
$if2_if = inet4(vmx1)
alg "icmp"
group "foo" on $if1_if {
ruleset "blacklistd"
}
group "bar" on $if2_if {
ruleset "blacklistd"
}
group default {
pass final on lo0 all
block all
}
-
I haven't investigated further yet. Ring any bells with anyone?
System is amd64 -current.
Regards,
Geoff
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: net/if_ipsec/t_ipsec:ipsecif_basic_ipv4overipv6_esp_null net/if_ipsec/t_ipsec:ipsecif_basic_ipv4overipv6_esp_rijndaelcbc net/if_ipsec/t_ipsec:ipsecif_basic_ipv6overipv6_esp_null net/if_ipsec/t_ipsec:ipsecif_basic_ipv6overipv6_esp_rijndaelcbc net/if_ipsec/t_ipsec:ipsecif_ioctl_ipv4overipv6_esp_null net/if_ipsec/t_ipsec:ipsecif_ioctl_ipv4overipv6_esp_rijndaelcbc net/if_ipsec/t_ipsec:ipsecif_ioctl_ipv6overipv6_esp_null net/if_ipsec/t_ipsec:ipsecif_ioctl_ipv6overipv6_esp_rijndaelcbc net/if_ipsec/t_ipsec:ipsecif_recursive_ipv4overipv6_esp_null net/if_ipsec/t_ipsec:ipsecif_recursive_ipv4overipv6_esp_rijndaelcbc net/if_ipsec/t_ipsec:ipsecif_recursive_ipv6overipv4_esp_null net/if_ipsec/t_ipsec:ipsecif_recursive_ipv6overipv4_esp_rijndaelcbc net/if_ipsec/t_ipsec:ipsecif_recursive_ipv6overipv6_esp_null net/if_ipsec/t_ipsec:ipsecif_recursive_ipv6overipv6_esp_rijndaelcbc The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2018.03.09.10.59.36 knakahara src/sys/net/if_ipsec.c,v 1.4 2018.03.09.11.01.41 knakahara src/sys/net/if_ipsec.c,v 1.5 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.03.html#2018.03.09.11.01.41
