mirror of
https://github.com/opnsense/src.git
synced 2026-06-06 23:32:52 -04:00
ecb3a7d43d
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. Reviewed by: vmaffione Obtained from: CheriBSD Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D49220 |
||
|---|---|---|
| .. | ||
| acl | ||
| aio | ||
| audit | ||
| auditpipe | ||
| cam | ||
| capsicum | ||
| cddl | ||
| common | ||
| compat32 | ||
| devrandom | ||
| fifo | ||
| file | ||
| fs | ||
| geom | ||
| kern | ||
| kqueue | ||
| mac | ||
| mqueue | ||
| net | ||
| netgraph | ||
| netinet | ||
| netinet6 | ||
| netipsec | ||
| netlink | ||
| netmap | ||
| netpfil | ||
| opencrypto | ||
| pjdfstest | ||
| posixshm | ||
| ses | ||
| sound | ||
| sys | ||
| vfs | ||
| vm | ||
| vmm | ||
| Makefile | ||
| Makefile.depend | ||
| Makefile.inc | ||