Fixes: 1d126e9b9474 carp: Widen epoch coverage
MFC after: 1 day
Details
On current or stable/13 with INVARIANTS, force a virtual host to be master from backup by ifconfig vhid 100 state master.
stable/12 is not affected.
#!/bin/sh kldload -nq carp ep=$( ifconfig epair create inet 192.168.1.1/24 ) ifconfig $ep vhid 100 advskew 100 192.168.1.100/32 alias ifconfig $ep vhid 100 state backup # The following will triggers assertion panic without the fix ifconfig $ep vhid 100 state master sleep 0.5 ifconfig $ep destroy
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
It'd be good to add this case to the carp tests. Can you? If not, I'll take a look. I'm doing some carp work as well anyway.
I'm not familiar with the atf test framework, and I have no bandwidth. I'm still struggling with route cache framework yet :(
BTW, without INVARIANTS, I have not encounter any problem even run the test script (as in TEST PLAN) multiple times. Maybe I have good luck, or there're something hide behind net epoch .
carp_master_down_locked() will call ip_output() , arprequest() and nd6_na_output() those all require net epoch. Although the ifp holds a reference but I think without net epoch the system will behave badly, possibly access freed memory.
Can @melifaro comment on this?
The epoch system serves to make sure that resources we rely on (such as the ifp, or route or neighbour objects) don't go away while we're using them. It's pretty unlikely for them to actually go away in the tiny slice of time where it'd matter, so it's completely normal that you didn't see any issues even with the missing epoch calls.
Kristof already replied, so just adding a few points here. Epoch provides safety guarantees that the objects we have pointers will not be freed. In a sense, it's somewhat similar to the locks - without them, the concurrent code will work, but not always.
I typically develop/test on the kernels w/ INVARIANTS first, as it really helps to catch issues early - as we've plenty of INVARIANTS-only asserts.
@kp @melifaro
Thanks for the explaining ;)
I typically develop/test on the kernels w/ INVARIANTS first, as it really helps to catch issues early - as we've plenty of INVARIANTS-only asserts.
Is it possible that some tools / compilers can catch customized ASSERTS such as NET_EPOCH_ASSERT and hint / blame unsatisfied conditions?
Although runtime tests are still needed but tests are always not enough .
Coverity could check some of these. But for the rest of the tools it's just writing some (or more) tests.
Although runtime tests are still needed but tests are always not enough .
There are some efforts for reduce the bar for writing kernel unit-tests like https://github.com/rysto32/freebsd/tree/sysunit , but we don't have it fully working yet.