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=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=ham 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 A39E1C432C0 for ; Tue, 3 Dec 2019 18:38:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 477E72073B for ; Tue, 3 Dec 2019 18:38:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 477E72073B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BD3376B0659; Tue, 3 Dec 2019 13:38:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B5CE96B065A; Tue, 3 Dec 2019 13:38:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A24476B065B; Tue, 3 Dec 2019 13:38:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) by kanga.kvack.org (Postfix) with ESMTP id 86D8A6B0659 for ; Tue, 3 Dec 2019 13:38:22 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 388805DF4 for ; Tue, 3 Dec 2019 18:38:22 +0000 (UTC) X-FDA: 76224690444.09.stone21_2be392001b44a X-HE-Tag: stone21_2be392001b44a X-Filterd-Recvd-Size: 4676 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Dec 2019 18:38:21 +0000 (UTC) Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7D03D206E4; Tue, 3 Dec 2019 18:38:16 +0000 (UTC) Date: Tue, 3 Dec 2019 13:38:15 -0500 From: Steven Rostedt To: Alexander Potapenko Cc: Qian Cai , 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 , Petr Mladek , Randy Dunlap , Robin Murphy , Sergey Senozhatsky , Takashi Iwai , "Theodore Ts'o" , Thomas Gleixner , Vasily Gorbik , Wolfram Sang Subject: Re: [PATCH RFC v3 18/36] kmsan: disable LOCK_DEBUGGING_SUPPORT Message-ID: <20191203133815.05a020fc@gandalf.local.home> In-Reply-To: References: <591B421C-F7AB-4394-83B5-AD3A86580C64@lca.pw> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 3 Dec 2019 16:14:17 +0100 Alexander Potapenko wrote: > On Tue, Dec 3, 2019 at 4:00 PM Qian Cai wrote: > > > > > > > > > On Dec 3, 2019, at 9:35 AM, Alexander Potapenko wrote: > > > > > > At this point I don't really know why KMSAN and lockdep don't play > > > well together, but I'm not expecting anyone to use them together > > > either. > > > > Of course people will use those together. For example, distro debug kernel variants. > Some tools are just not designed to work together. > For example, you won't be able to compile the kernel with both KASAN > and KMSAN enabled at the same time. > > Lockdep doesn't require any instrumentation to work, so it _might_ be > possible to make it work with KMSAN, but it will probably still slow > down the things to an unacceptable level. > I'm inclining towards disabling the two together for now, unless > anyone is willing to address that issue. Note, I'm much more interested in someone running with lockdep than with KMSAN. Thus, you may not get as much use if you do not work with lockdep. I enable lockdep first when testing out my code. If KMSAN is not compatible, it wont get enabled. > > Please let me know if you think I need to keep the link to > https://github.com/google/kmsan/issues/57 in the Kconfig comment, > right now it looks like: > > # KMSAN is currently incompatible with lockdep. > Function tracing had lots of issues with lockdep, but I worked hard to make sure they could be compatible. This usually required having the lockdep code not be traced. Is it possible to have the same with KMSAN. That is, have KMSAN not look at anything that lockdep does? -- Steve