On Tue, 11 Nov 2014 10:21:42 +0300 Andrey Ryabinin <a.ryabinin@xxxxxxxxxxx> wrote: > Hi Andrew, > > Now we have stable GCC(4.9.2) which supports kasan and from my point of view patchset is ready for merging. > I could have sent v7 (it's just rebased v6), but I see no point in doing that and bothering people, > unless you are ready to take it. It's a huge pile of tricky code we'll need to maintain. To justify its inclusion I think we need to be confident that kasan will find a significant number of significant bugs that kmemcheck/debug_pagealloc/slub_debug failed to detect. How do we get that confidence? I've seen a small number of minorish-looking kasan-detected bug reports go past, maybe six or so. That's in a 20-year-old code base, so one new minor bug discovered per three years? Not worth it! Presumably more bugs will be exposed as more people use kasan on different kernel configs, but will their number and seriousness justify the maintenance effort? If kasan will permit us to remove kmemcheck/debug_pagealloc/slub_debug then that tips the balance a little. What's the feasibility of that? Sorry to play the hardass here, but someone has to ;) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>