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=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 10347C33CA1 for ; Thu, 9 Jan 2020 16:30:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B379A2067D for ; Thu, 9 Jan 2020 16:30:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B379A2067D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 09C648E0021; Thu, 9 Jan 2020 11:30:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 03C588E0017; Thu, 9 Jan 2020 11:30:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2E7C8E0021; Thu, 9 Jan 2020 11:30:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0228.hostedemail.com [216.40.44.228]) by kanga.kvack.org (Postfix) with ESMTP id C9DCC8E0017 for ; Thu, 9 Jan 2020 11:30:18 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 544C1824934B for ; Thu, 9 Jan 2020 16:30:18 +0000 (UTC) X-FDA: 76358633316.02.kiss13_3cc476345e101 X-HE-Tag: kiss13_3cc476345e101 X-Filterd-Recvd-Size: 4162 Received: from Galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Thu, 9 Jan 2020 16:30:17 +0000 (UTC) Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ipago-0007PZ-HN; Thu, 09 Jan 2020 17:29:42 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 526E0105F59; Thu, 9 Jan 2020 17:29:41 +0100 (CET) From: Thomas Gleixner To: Alexander Potapenko , Leon Romanovsky Cc: Alexander Viro , Andreas Dilger , Andrew Morton , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Christoph Hellwig , Christoph Hellwig , "Darrick J. Wong" , "David S. Miller" , Dmitry Torokhov , Dmitry Vyukov , Eric Biggers , Eric Dumazet , Eric Van Hensbergen , Greg Kroah-Hartman , Harry Wentland , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jason Wang , Jens Axboe , Marek Szyprowski , Marco Elver , Mark Rutland , "Martin K. Petersen" , Martin Schwidefsky , Matthew Wilcox , "Michael S. Tsirkin" , Michal Simek , Petr Mladek , Qian Cai , Randy Dunlap , Robin Murphy , Sergey Senozhatsky , Steven Rostedt , Takashi Iwai , Theodore Ts'o , Vasily Gorbik , Vegard Nossum , Wolfram Sang , Linux Memory Management List , Michal Hocko Subject: Re: [PATCH RFC v4 00/42] Add KernelMemorySanitizer infrastructure In-Reply-To: References: <20191220184955.223741-1-glider@google.com> <20191223075141.GK13335@unreal> Date: Thu, 09 Jan 2020 17:29:41 +0100 Message-ID: <878smg385m.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 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: Alexander Potapenko writes: >> > 2. checkpatch.pl complains a lot about the use of BUG_ON in KMSAN >> > source. I don't have a strong opinion on this, but KMSAN is a debugging >> > tool, so any runtime invariant violation in it renders the tool useless. >> > Therefore it doesn't make much sense to not terminate after a bug in >> > KMSAN. >> >> Such early termination will cause hard time for verification teams >> execute any major test suite with KMSAN till it will be without any bugs. >> So yes, I think that the best solution is to avoid BUG_ONs in non-critical code. >> > > To clarify, these BUG_ONs are for bugs in KMSAN itself. KMSAN reports > don't provoke a BUG(), so many of them can be reported at once. > Proceeding after a bug in the debugging tool itself might be a bad > idea - any broken invariant denotes that all following reports may be > incorrect. Correct, unless you can gracefully disable the debugging tool and just continue which would be the best solution. Thanks, tglx