From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28161C2BC73 for ; Wed, 4 Dec 2019 18:03:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CAB5C20675 for ; Wed, 4 Dec 2019 18:03:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="MRttwz54" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAB5C20675 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 608946B0B71; Wed, 4 Dec 2019 13:03:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 591E56B0B76; Wed, 4 Dec 2019 13:03:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 432B16B0BBB; Wed, 4 Dec 2019 13:03:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) by kanga.kvack.org (Postfix) with ESMTP id 27C816B0B71 for ; Wed, 4 Dec 2019 13:03:22 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id D78AA181AEF30 for ; Wed, 4 Dec 2019 18:03:21 +0000 (UTC) X-FDA: 76228231002.09.range05_576e492647c4b X-HE-Tag: range05_576e492647c4b X-Filterd-Recvd-Size: 6878 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Dec 2019 18:03:20 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id p5so621076qtq.12 for ; Wed, 04 Dec 2019 10:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=wLvQxx58DqsGZUV/Z2yZToufbnAGN84Cy84rklpqQyc=; b=MRttwz54UECv5EkZJvvbOE+p9gad7RKUUIBdHPMGLMbiSKMdT/pz7TV4U7yk1DIVFu FtbfGXq6dKYAPOnPlUL6r5MwdyyjfIE4JQJLixY3+SFpKdg//5lngtZb0+7oYYkLfNem 9tSJYai5WBOX604Du23lB2I9WK6LcDpOBNqlz69Naqx/u1hZP/0nW2Qx6oIWwDp9aGzI Pw505OcgeYGXrWH0ka0jq2sRbSWtkXwfgwDyHBATF9e8DAUxGkqqwE0ZsZTPDfk2b0Kc TSZAfCEYbZxsIH87fAqkGEdbvPmr5pN6FyJjH4iYhGiEV8QqRoZGpqpTGKblkvQy3e5l QqKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=wLvQxx58DqsGZUV/Z2yZToufbnAGN84Cy84rklpqQyc=; b=o9aKTGQFXgKSfBbA42i83zN5a+QhWyqq/XLnTJWeW/qKdqUtKofTX60+9OyyhikyEu NEIGNadervu8LCFrJX49DrB5XwvRj+tmm8cmwK+JpEowEa3dstymYh7dxuGv3ewWlYYL Zsw6A9iCuc3KX80XSofFTl0RS6XrvzuchvvTWiKlpz37KiRdBa1xurnBDc3/TjrFkNXP rwbrxEUt9cdG49iA6KEsy1wLYlYPU3mXJ1W3JGtRJT8HZ4Q7o/RAbE7zmz8dA/m8N9Q/ +lSLFutuoKPPCc0IjfFCBg+5swwxlJ/0tlgaUuf14st9XrwwetOY7GUTCejBAIJKBhYR 16nQ== X-Gm-Message-State: APjAAAXiIJdsQWLZS/S5hq08ZbZ3EqtyhTEp8dv//jyUkWlBbK0jv8dV IOGtbAyRBGXzGePA191NKppOXQ== X-Google-Smtp-Source: APXvYqx7F/WRc0NFGKqST6OVBc3lDGKRUfqz4/aqJa0FQDsWqKC7nws6FGfVbZ/BfaRlR88QMMHp5Q== X-Received: by 2002:ac8:22c4:: with SMTP id g4mr3962487qta.45.1575482599882; Wed, 04 Dec 2019 10:03:19 -0800 (PST) Received: from [192.168.1.183] (pool-71-184-117-43.bstnma.fios.verizon.net. [71.184.117.43]) by smtp.gmail.com with ESMTPSA id c184sm4069336qke.118.2019.12.04.10.03.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Dec 2019 10:03:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Qian Cai Mime-Version: 1.0 (1.0) Subject: Re: [PATCH RFC v3 18/36] kmsan: disable LOCK_DEBUGGING_SUPPORT Date: Wed, 4 Dec 2019 13:03:18 -0500 Message-Id: <35EF55C2-C46E-4853-8BA8-0F113DD13812@lca.pw> References: Cc: Petr Mladek , Steven Rostedt , Marco Elver , Eric Biggers , Christoph Hellwig , Herbert Xu , Harry Wentland , Vegard Nossum , Dmitry Vyukov , Linux Memory Management List , Al Viro , Andreas Dilger , Andrew Morton , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Christoph Hellwig , "Darrick J. Wong" , "David S. Miller" , Dmitry Torokhov , Eric Dumazet , Eric Van Hensbergen , Greg Kroah-Hartman , Ilya Leoshkevich , Ingo Molnar , Jason Wang , Jens Axboe , Marek Szyprowski , Mark Rutland , "Martin K. Petersen" , Martin Schwidefsky , Matthew Wilcox , "Michael S. Tsirkin" , Michal Simek , Randy Dunlap , Robin Murphy , Sergey Senozhatsky , Takashi Iwai , Theodore Ts'o , Thomas Gleixner , Vasily Gorbik , Wolfram Sang In-Reply-To: To: Alexander Potapenko X-Mailer: iPhone Mail (17B111) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Dec 4, 2019, at 11:24 AM, Alexander Potapenko wrote= : >=20 > 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). >=20 > =46rom 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. >=20 > 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 ker= nel. Those tend to break over time mainly because not many paid kernel devel= opers 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 o= f the kernel because those debugging options does not generate revenues. For= example, kmemleak was broken on NUMA for many releases and lockdep PROVE_LO= CKING still has too many unfixed splats right now which would render it almo= st 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 ye= t nobody put any effort to consolidate them. It is even more cumbersome for t= he options to break without notice because it does not play well with popula= r ones like KASAN given code for those features are spanning all over the ke= rnel code base, so they are sensitive to changes from other subsystems. It p= ut a burden for bug hunters to enable them because it is going to be expensi= ve increasing test runs time exponentially and maintenance cost of different= debug kernels.=