Re: [PATCH RFC v3 18/36] kmsan: disable LOCK_DEBUGGING_SUPPORT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Dec 4, 2019, at 11:24 AM, Alexander Potapenko <glider@xxxxxxxxxx> wrote:
> 
> One can think of KMSAN as a _fast_ replacement of kmemcheck.
> Unfortunately, the latter bit-rotted at some point and was deleted
> from the kernel (I don't think distro debug kernels ever used it
> though).
> 
> From our experience building userspace tools, making KMSAN and KASAN
> work together isn't worth it.
> The resulting monster will be slower than any of the two tools and
> will be using more memory than both of them together.
> This means that anyone who's using at least two machines for fuzzing
> or continuous integration will prefer running two different tools on
> them instead of running KMSAN+KASAN together on every machine.
> 
> That said, I'll try my best to keep existing low-overhead debug
> configs working with KMSAN, but it still won't solve the need of
> running orthogonal kernel configs for testing.

The problem is that we have too many memory-related debugging options in kernel. Those tend to break over time mainly because not many paid kernel developers would care about them, and most of Kernel developers nowadays are paid.  Not many employers would like Google to spend money on long-term health of the kernel because those debugging options does not generate revenues. For example, kmemleak was broken on NUMA for many releases and lockdep PROVE_LOCKING still has too many unfixed splats right now which would render it almost useless for general debugging because it will disable itself after found a splat.

Every of those does somewhat different and yet have many overlapping that yet nobody put any effort to consolidate them. It is even more cumbersome for the options to break without notice because it does not play well with popular ones like KASAN given code for those features are spanning all over the kernel code base, so they are sensitive to changes from other subsystems. It put a burden for bug hunters to enable them because it is going to be expensive increasing test runs time exponentially and maintenance cost of different debug kernels.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux