Intel's Bus Lock Detection Might Be Ready For The Mainline Linux Kernel
For longer than the past year Intel engineers have been working on wiring up the Linux kernel support to handle split lock detection and bus lock detection. Back in Linux 5.7 the split lock detection landed for warning or even killing the offending software should a split lock occur due to the significant performance impact and possible denial of service. Now it's looking like the bus lock detection code could be ready for mainline.
After the split lock detection code was merged, Intel engineers turned their focus to bus lock detection for Linux. Again, important due to the performance penalties and possible denial of service implications. Bus locks can disrupt the performance to other CPU cores and are much slower than an atomic operation happening within a cache line. Like the split lock detection, the bus lock detection relies upon the CPU being able to notify the kernel when a user instruction acquires a bus lock.
Yesterday tip/tip.git's x86/splitlock branch picked up these bus lock detection patches from Intel's Fenghua Yu. Thus assuming nothing major comes up, it's likely next to be sent in as a pull request as part of changes for Linux 5.13.
Whether a given CPU supports the bus lock detection will be exposed on future versions of the kernel by the new "bus_lock_detect" feature flag within /proc/cpuinfo.
The handling makes use of the same split_lock_detect= option introduced for the split lock handling. For the bus lock detection there are the options of doing nothing, warning once per task, killing the task by sending SIGBUS to user, or rate limiting the bus lock to a given number of times per second for non-root users. The default behavior with the patches on supported CPUs will be to just warn the user once per task to the kernel log.
See the latest documentation for more details on the split / bus lock detection for Linux.
After the split lock detection code was merged, Intel engineers turned their focus to bus lock detection for Linux. Again, important due to the performance penalties and possible denial of service implications. Bus locks can disrupt the performance to other CPU cores and are much slower than an atomic operation happening within a cache line. Like the split lock detection, the bus lock detection relies upon the CPU being able to notify the kernel when a user instruction acquires a bus lock.
Yesterday tip/tip.git's x86/splitlock branch picked up these bus lock detection patches from Intel's Fenghua Yu. Thus assuming nothing major comes up, it's likely next to be sent in as a pull request as part of changes for Linux 5.13.
Whether a given CPU supports the bus lock detection will be exposed on future versions of the kernel by the new "bus_lock_detect" feature flag within /proc/cpuinfo.
The handling makes use of the same split_lock_detect= option introduced for the split lock handling. For the bus lock detection there are the options of doing nothing, warning once per task, killing the task by sending SIGBUS to user, or rate limiting the bus lock to a given number of times per second for non-root users. The default behavior with the patches on supported CPUs will be to just warn the user once per task to the kernel log.
See the latest documentation for more details on the split / bus lock detection for Linux.
1 Comment