On Wed, Dec 13, 2017 at 9:27 PM, Andreas Gustafsson <[email protected]> wrote:
> NetBSD Test Fixture wrote:
>> The newly failing test cases are:
>>
>>     fs/vfs/t_mtime_otrunc:puffs_otrunc_mtime_update
>>     net/route/t_change:route_change_ifp
>>     net/route/t_change:route_change_ifp_ifa
>>
>> 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:
>>
>>     2017.12.11.02.33.17 knakahara src/sys/kern/subr_psref.c,v 1.8
>>     2017.12.11.02.33.17 knakahara src/sys/sys/psref.h,v 1.3
>>     2017.12.11.03.25.45 ozaki-r src/sys/net/if.c,v 1.412
>>     2017.12.11.03.25.45 ozaki-r src/sys/net/if.h,v 1.252
>>     2017.12.11.03.25.46 ozaki-r src/sys/net/npf/npf_ifaddr.c,v 1.3
>>     2017.12.11.03.25.46 ozaki-r src/sys/net/npf/npf_os.c,v 1.9
>>     2017.12.11.03.29.20 ozaki-r src/sys/net/if.c,v 1.413
>>     2017.12.11.03.29.20 ozaki-r src/sys/net/if.h,v 1.253
>>     2017.12.11.03.29.20 ozaki-r src/sys/net/if_bridge.c,v 1.145
>>     2017.12.11.03.29.20 ozaki-r src/sys/net/if_spppsubr.c,v 1.177
>>     2017.12.11.03.29.20 ozaki-r src/sys/net/if_vlan.c,v 1.119
>>     2017.12.11.03.29.20 ozaki-r 
>> src/sys/rump/net/lib/libnetinet/netinet_component.c,v 1.10
>
> Also, the tests now leave two rump_server processes looping in the
> background:
>
>   UID   PID PPID    CPU PRI NI   VSZ   RSS WCHAN   STAT TTY        TIME 
> COMMAND
>     0  4433    1 310129  27  0 74696  4024 -       Rsl  ?     194:32.70 
> rump_server -lrumpdev -lrumpnet -lrumpnet_net -lrumpnet_netin
>     0 20356    1 666580  27  0 73884  4024 -       Rsl  ?     216:32.72 
> rump_server -lrumpdev -lrumpnet -lrumpnet_net -lrumpnet_netin
>
> This is slowing down the test VMs enough to make some of the test runs
> time out.
> --
> Andreas Gustafsson, [email protected]

Fixed in -current.

The cause of the failures was a bug which calls psref_release to an ifa twice
in rtsock.c, not due to the change to psref.

It seems that changing from LIST to SLIST revealed the bug. LIST could
resist the
bug (LIST_REMOVE can be called twice to an item without errors if the list isn't
modified between the removals) while SLIST couldn't.

  ozaki-r

Reply via email to