http://bugzilla.suse.com/show_bug.cgi?id=1127808 http://bugzilla.suse.com/show_bug.cgi?id=1127808#c3 --- Comment #3 from Mel Gorman --- First off, SLAB_FREELIST_HARDENED is not an option for us as it depends on SLUB which we never switched to. If we want that, we'd first have to consider the SLUB switch and what that means and then the SLAB_FREELIST_HARDENED so only HARDENED_USERCOPY was considered. Short answer -- I've no objection but there are limits to the testing methodology used to measure this. Networking loads appear to be the ones most likely to notice. Overall we're looking at a general hit of 0-8% hit depending on the workload. I'm somewhat wary of enabling it just because everybody else does but the type of attack it protects against is realistic. That said, I did not do a proper networking test between hosts and used localhost only. The changelog introducing the entry mentioned 5-8% drop on UDP on what I *think* was a host-to-host setup which is relatively rare. It looks like we take a hit communicating via localhost too. In the tests I did, there is measurable overhead but it's not too insane and it's not universal. I'd rather not have it but we've taken hits for security mitigation before. Very broadly speaking, there is an increase in system CPU usage but it's hard to detect from headline performance metrics. The most obvious hit is to networking loads running on localhost dbench (lots of copying) showed a mix of performance differences that were close to the noise but looks like it's about 3% at worst and usually around the 1% mark. System CPU usage is 1% higher. pgbench in a read-only small memory configuration (some kernel copying, mostly shared memory areas) showed very little difference. Roughly 0-2% of a hit but it was not a universal loss with results close to the noise. System CPU usage is 5% higher. specjbb shows almost no difference as it does not have a large kernel footprint. Overhead is negligible. Similarly the NAS Parallel Benchmark shows almost no difference as it has a negligible kernel component. This was known in advance but I just wanted to make the point that for some "high performance" workloads, there will be no impact due to this configuration change. Netperf TCP_STREAM and UDP_STREAM both take a 2-5% hit depending on the buffer size which is curious given that the system CPU usage is almost unchanged. I suspect in practice this might only be of concern on very high speed networks or host-to-host configurations. In those instances, they are likely to notice the check overhead in perf and disable accordingly. Similarly, tbench takes a 2-5% performance hit. Also similarly, hackbench communicating over sockets takes a 3% hit but communicating over pipes is fine. Compile-based workload (specifically a kernel build) was almost unaffected. I say almost because for some reason -j4 took a massive hit (20% on two separate machines with very different configurations) while other -j values show 0-1% differences well within noise. This is definitely the most curious result and I do not have a good explanation as to why -j4 matters so much. So overall, it's far from free no matter was Kees Cook says but I think relatively few people are going to notice and if they do, it's relatively trivial to detect with perf -- level of relative depending on comfort level with perf. Thanks for bringing me into the loop on this one Jiri. It's the type of thing I do not like to get blind sided by. -- You are receiving this mail because: You are on the CC list for the bug.