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

From: Qian Cai <cai@lca.pw>
To: Alexander Potapenko <glider@google.com>
Cc: Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Marco Elver <elver@google.com>,
	Eric Biggers <ebiggers@google.com>,
	Christoph Hellwig <hch@lst.de>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Harry Wentland <harry.wentland@amd.com>,
	Vegard Nossum <vegard.nossum@oracle.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrey Konovalov <andreyknvl@google.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Andy Lutomirski <luto@kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Christoph Hellwig <hch@infradead.org>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	"David S. Miller" <davem@davemloft.net>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Eric Dumazet <edumazet@google.com>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>, Ingo Molnar <mingo@elte.hu>,
	Jason Wang <jasowang@redhat.com>, Jens Axboe <axboe@kernel.dk>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Matthew Wilcox <willy@infradead.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Michal Simek <monstr@monstr.eu>,
	Randy Dunlap <rdunlap@infradead.org>,
	Robin Murphy <Robin.Murphy@arm.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Takashi Iwai <tiwai@suse.com>, Theodore Ts'o <tytso@mit.edu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Wolfram Sang <wsa@the-dreams.de>
Subject: Re: [PATCH RFC v3 18/36] kmsan: disable LOCK_DEBUGGING_SUPPORT
Date: Wed, 4 Dec 2019 13:03:18 -0500	[thread overview]
Message-ID: <35EF55C2-C46E-4853-8BA8-0F113DD13812@lca.pw> (raw)
In-Reply-To: <CAG_fn=UhprbSxTW-CVsxKfrwOt-p2OEnbLa+R0Xs2coJ+699bw@mail.gmail.com>

> On Dec 4, 2019, at 11:24 AM, Alexander Potapenko <glider@google.com> 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.