This is totally self-serving (and employer-serving), but has anybody thought about this large collection of memory debugging tools that we are growing? It helps to have them all in the same places in the menus (thanks for adding it to Memory Debugging, btw!). But, this gives us at least four things that overlap with kasan's features on some level. Each of these has its own advantages and disadvantages, of course: 1. DEBUG_PAGEALLOC 2. SLUB debugging / DEBUG_OBJECTS 3. kmemcheck 4. kasan ... and there are surely more coming down pike. Like Intel MPX: > https://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions Or, do we just keep adding these overlapping tools and their associated code over and over and fragment their user bases? You're also claiming that "KASAN is better than all of CONFIG_DEBUG_PAGEALLOC". So should we just disallow (or hide) DEBUG_PAGEALLOC on kernels where KASAN is available? Maybe we just need to keep these out of mainline and make Andrew carry it in -mm until the end of time. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
