On Tue, Feb 05, 2019 at 04:43:09PM +0100, Borislav Petkov wrote: > On Tue, Feb 05, 2019 at 07:19:16AM -0800, Dave Hansen wrote: > > This is one of the few times that we're pretty confident that folks will > > use this. The reason we're going to this trouble is that the split lock > > detection is wanted by actual customers, and they want it before it's > > implemented on a processor with real enumeration. > > > > This isn't something we want everybody and their grandma to turn on; > > it's a rather specialized feature. It's really only for folks that care > > about the latency incurred across the entire system on split lock > > operations. > > ... > > > It's not for developers. This really is for (somewhat niche) end users > > that want split lock detection in production. This is all really an > > effort to get them running mainline or real distro kernels. > > This all sounds to me like it shouldn't even be mainline but in a > special, evaluation kernel. If anything, it should be default off and be > opted-in by a cmdline switch. None of that *cpuid=* toggling dance
In the cover patch, we gave three real usage cases for this feature: This capability is critical for real time system designers who build consolidated real time systems. These systems run hard real time code on some cores and run "untrusted" user processes on some other cores. The hard real time cannot afford to have any bus lock from the untrusted processes to hurt real time performance. To date the designers have been unable to deploy these solutions as they have no way to prevent the "untrusted" user code from generating split lock and bus lock to block the hard real time code to access memory during bus locking. This capability may also find usage in cloud. A user process with split lock running in one guest can block other cores from accessing shared memory during its split locked memory access. That may cause overall system performance degradation. Split lock may open a security hole where malicious user code may slow down overall system by executing instructions with split lock. In the usage cases, end users (not developers) want to turn on the feature in their production lines (not evaluation) to detect split lock issues which can come not only from legacy apps but also from malicious code or newly started apps any time during run time. Thanks. -Fenghua