On Tue, 17 Sep 2019, Qian Cai wrote: > > The cmpxchg failures could likely be more generalized beyond SLUB since > > there will be other dependencies in the kernel than just this allocator. > > OK, SLUB_RESILIENCY_TEST is fine to keep around and maybe be turned into a > Kconfig option to make it more visible. > > Is it fine to remove SLUB_DEBUG_CMPXCHG? If somebody later want to generalize it > beyond SLUB, he/she can always find the old code somewhere anyway. > Beyond the fact that your patch doesn't compile, slub is the most notable (only?) user of double cmpxchg in the kernel so generalizing it would only serve to add more indirection at the moment. If/when it becomes more widely used, we can have a discussion about generalizing it so that we can detect failures even when SLUB is not used. Note that the primary purpose of the option is to diagnose issues when the CMPXCHG_DOUBLE_FAIL is observed. If we encounter that, we wouldn't have any diagnostic tools to look deeper without adding this code back. So I don't think anything around cmpxchg failure notifications needs to be changed right now.
