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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 43483C43603 for ; Wed, 4 Dec 2019 16:24:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EA857206DB for ; Wed, 4 Dec 2019 16:24:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="BP536c3k" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA857206DB Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7B1E16B0B80; Wed, 4 Dec 2019 11:24:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 762156B0B82; Wed, 4 Dec 2019 11:24:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 651B06B0B83; Wed, 4 Dec 2019 11:24:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0123.hostedemail.com [216.40.44.123]) by kanga.kvack.org (Postfix) with ESMTP id 501546B0B80 for ; Wed, 4 Dec 2019 11:24:22 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 0C82D3D12 for ; Wed, 4 Dec 2019 16:24:22 +0000 (UTC) X-FDA: 76227981564.15.use10_6039cd7677059 X-HE-Tag: use10_6039cd7677059 X-Filterd-Recvd-Size: 7629 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Dec 2019 16:24:21 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id f129so388417wmf.2 for ; Wed, 04 Dec 2019 08:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wLixRvj1cBxIygfi65k5tlgYBw9vl1SdxxDm48IclVU=; b=BP536c3k4uuX39EmWXZWXDQy8PiU7MtbX527kTnTTyPmD/rB2CTjMm/gG4HFKCc8Mw 5F0NrJ0O5I+b0vbdX+zw2JgmbrfX1g0iV95nBFIcthmgy1YWmwzrXX+5nTLMz9NVRQfG Z0Rmz/ynbg9OPXPItD9J5IbbushJwE3LDRHljLUOpphe7xwrQgoY214DMS6m83pKgFmv ilQY4MtkMDMHQGRbxbrtz24pG1ENNLI5A4e8oCqkTfkdD2ALNeZHHfDPe/5aJEVxoKea utNejMufcq76MIFDEWNJZBgZ6kjfZM7rUzDEybtk9lZqW4mtr4KxbX4TDsI2wwoPD6Lq ckDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wLixRvj1cBxIygfi65k5tlgYBw9vl1SdxxDm48IclVU=; b=Vi/gf0bWkK2hXXVzL8pCK7549twQ+hqq7j1LeC9mLIeacxUogTXmcLwobFWkdgsfLC CVqpW0hAYjBOLuwE/yhYuc7RyIfgikTsm68OKrmOgbzQCj4oXSw6FLxbnrwsY4q3rQAg MyPphZdJcZuRcVyDNv4hGuEUN+76AJzu0cX1ECkMm368UobRrBoquwe4SM3rnspZ6Wut UXvfRerYvN5acI7VyHikbA9Gcivbv/sNq79k9/bcaGpqaOZvDRkiADZinxgRCTcOLZ/X cFiI1nEgZRwBi1JIRiOmzn7IwhJy7yfk1COHaZIRsF13vSxTg8VM9aXAulxjh8TgZu7A DWiw== X-Gm-Message-State: APjAAAXBThlj9jbcP0lJ2zhHpnEem4wv+GOtdKgxwcYiLiA8U9H3dLSq lPX4T8TVwDJ+jOvQapPtHXD6aNHTEw0tPSk/BR9OLA== X-Google-Smtp-Source: APXvYqwpVVbfWWXjBL607KmSGWaAfcpWdtMxx0B+wn/Ydw20co0sE2/oxB2fr0dzoC88xD3NjRvnBW3y8FCYdJ0eacI= X-Received: by 2002:a7b:cb46:: with SMTP id v6mr403084wmj.117.1575476659268; Wed, 04 Dec 2019 08:24:19 -0800 (PST) MIME-Version: 1.0 References: <20191204122212.ziwntau5hrokrpmk@pathway.suse.cz> <132F741E-700C-42F4-923E-53454E036E81@lca.pw> In-Reply-To: <132F741E-700C-42F4-923E-53454E036E81@lca.pw> From: Alexander Potapenko Date: Wed, 4 Dec 2019 17:24:07 +0100 Message-ID: Subject: Re: [PATCH RFC v3 18/36] kmsan: disable LOCK_DEBUGGING_SUPPORT To: Qian Cai 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Wed, Dec 4, 2019 at 2:12 PM Qian Cai wrote: > > > > > On Dec 4, 2019, at 7:22 AM, Petr Mladek wrote: > > > > IMHO, a generic distro debug kernel could not enable debugging > > options that would significantly slow down the kernel. Most users > > would refuse using such kernels. Also they might slow down > > the system to the point that many problems won't be visible. > > > > For example, I do not see KASAN enabled in SUSE debug kernel. > > I guess that it will be the same with KMSAN. These options > > can be enabled in custom kernels when debugging particular > > problems. > > No, KASAN is one of most important debug options to find general issues. = It was actually used in many debug kernels like those in Google. In contras= t, it will find many issues compared to without even though the performance= would suffer in some degrees. > > I would even argue that since KASAN is so valuable that it is also desira= ble to get KMSAN to work together with KASAN by improving the compilers. Ot= herwise, it is a struggling to choose between KASAN and KMSAN for general d= ebug kernels as KASAN could also cover a subset of KMSAN coverage. Turns out it was fairly easy to make KMSAN work with lockdep, sorry for the noise. I'll send the updated patch that disables instrumentation of kernel/locking/lockdep.c in v4. While on this, I want to make a point on KMSAN features that seem to be misunderstood. KMSAN uses precise bit-to-bit shadow mapping and compiler instrumentation for shadow tracking to tell whether a value is used in a comparison, pointer dereference or is copied to hardware or userspace. As long as the use of such value doesn't cause an immediate crash or a memory corruption, KASAN is simply unable to detect such bugs. Neither are any other existing tools, although they may also report errors later, after the use of uninitialized values. There's a list of bugs found by syzbot running KMSAN (https://syzkaller.appspot.com/upstream/fixed?manager=3Dci-upstream-kmsan-g= ce), and I would say more than a hundred of those is unique to KMSAN. 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. --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg