Searched hist:295563 (Results 1 - 1 of 1) sorted by relevance
| /freebsd-11-stable/sys/arm64/arm64/ | ||
| H A D | swtch.S | diff 295563 Fri Feb 12 10:52:51 MST 2016 andrew Only update curthread and curpcb after we have finished using the old values. If switching from a thread that used floating-point registers to a thread that is still running, but holding the blocked_lock lock we would switch the curthread to the new (running) thread, then call critical_enter. This will non-atomically increment td_critnest, and later call critical_exit to non-atomically decrement this value. This can happen at the same time as the new thread is still running on the old core, also calling these functions. In this case there will be a race between these non-atomic operations. This can be an issue as we could loose one of these operations leading to the value to not return to zero. If, later on, we then hit a data abort we check if the td_critnest is zero. If this check fails we will panic the kernel. This has been observed when running pcmstat on a Cavium ThunderX. The pcm thread will use the blocked_lock lock and there is a high chance userspace will use the floating-point registers. When, later on, pmcstat triggers a data abort we will hit this panic. The fix is to update these values after storing the floating-point state. This means we use the correct curthread while storing the state so it will not be an issue that the changes to td_critnest are non-atomic. Sponsored by: ABT Systems Ltd |
Completed in 132 milliseconds