This test starts two threads to verify that two concurrent threads
cannot enter the kernel loop on the same netmap context. The test
even has a comment about a potential race condition where the first
thread enters the loop and is stopped before the second thread tries
to enter the loop. It claims it is fixed by the use of a semaphore.
Unfortunately, the semaphore doesn't close the race.
In the CI setup for CHERI, we run the testsuite once a week against
various architectures using single CPU QEMU instances. Across
multiple recent runs of the plain "aarch64" test the job ran for an
entire day before QEMU was killed by a timeout. The last messages
logged were from this test:
734.881045 [1182] generic_netmap_attach Emulated adapter for tap3312 created (prev was NULL)
734.882340 [ 321] generic_netmap_register Emulated adapter for tap3312 activated
734.882675 [2224] netmap_csb_validate csb_init for kring tap3312 RX0: head 0, cur 0, hwcur 0, hwtail 0
734.883042 [2224] netmap_csb_validate csb_init for kring tap3312 TX0: head 0, cur 0, hwcur 0, hwtail 1023
734.915397 [ 820] netmap_sync_kloop kloop busy_wait 1, direct_tx 0, direct_rx 0, na_could_sleep 0
736.901945 [ 820] netmap_sync_kloop kloop busy_wait 1, direct_tx 0, direct_rx 0, na_could_sleep 0
From the timestamps, the synchronous kloop was entered twice 2 seconds
apart. This corresponds to the 2 second timeout on the semaphore in
the test. What appears to have happened is that th1 started and
entered the kernel where it spun in an endless busy loop. This
starves th2 so it _never_ runs. Once the semaphore times out, th1 is
preempted to run the main thread which invokes the ioctl to stop the
busy loop. th1 then exits the loop and returns to userland to exit.
Only after this point does th2 actually run and execute the ioctl to
enter the kernel. Since th1 has already exited, th2 doesn't error and
enters its own happy spin loop. The main thread hangs forever in
pthread_join, and the process is unkillable (the busy loop in the
kernel doesn't check for any pending signals so kill -9 is ignored and
ineffective).
I don't see a way to fix this test, so I've just disabled it. There
is no good way to ensurce concurrency on a single CPU system when one
thread wants to sit in a spin loop. Someone should fix the netmap
kloop to respond to kill -9 in which case kyua could perhaps at least
timeout the individual test process and kill it.
Sponsored by: AFRL, DARPA
Obtained from: CheriBSD