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,URIBL_BLOCKED,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 9B426C43141 for ; Tue, 19 Nov 2019 19:54:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 737142245F for ; Tue, 19 Nov 2019 19:54:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="oURkgRgG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727334AbfKSTy1 (ORCPT ); Tue, 19 Nov 2019 14:54:27 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:39627 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726892AbfKSTy1 (ORCPT ); Tue, 19 Nov 2019 14:54:27 -0500 Received: by mail-ot1-f65.google.com with SMTP id w24so18570598otk.6 for ; Tue, 19 Nov 2019 11:54:26 -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=EhLUhFf+dWrZRS+as37pEKZIEswUZkBGb2xI++P3+j8=; b=oURkgRgGWUkSxDSZ1GZcf9JKZThTVFiPnKTPYV6+NAQo4qwintbC2XWKkuqirZuVFU bTYZKRscOUCeu16ZKaeZ3gXmUectwJqraAkzc8IBVgzlI8PbblowyxH6P3Ln12UZk9iO Pl0kfXxMBXKjXj6d8JggILhmHIA8f4ZCcFz6nGlkz7lVmiWjRLK+0aGRrkffeyuCuNkI 0zslGM9F/hSRR4n8JF2dvLzZiZ64O/OcPnSgVvg+FuFKwOq/W9YtVItB909hWO3GwyqT +0ZUwJKbggzqgLthIVoIszbE1Prv8ek/hgwno+wjPrrY7IKe9Gu3nZy0IvutjK5EGayQ o9iA== 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=EhLUhFf+dWrZRS+as37pEKZIEswUZkBGb2xI++P3+j8=; b=ao7IzcCYn+BLe82gv3gtDL/3O8S62YhtFgQ9AWSB+Puh859cxqYFTJG7PJz9dVgtbe WvUjsDv+1Wc5jdtzx4X6+wkjfgDEsPUpcfMtH+cVA6+XbYma715ipmRf9fQDKZBmxPVn kgFw9H1HenNt8ROo0nivLuIR2BIyko3MAfwybKbbWTBPViOze99HkkmfzSklSL3B5l/F WgHg27Zty4I1+QD8Id0YUpzcScxmEn11zDpPFICG+Dd4S1z4UZiSt7LBuL4UvwQsVhtY xBQpLnHvdjEwZ8yJ2mLRpHrlfSTu61ImcYzxh4mOh9d4l2QhetWpDoMo1AaXepi6H7WN DiVg== X-Gm-Message-State: APjAAAUZjIhJ0QhgXns9rukcZjwqLxjw98h5h2Pw/wnyVPg7H6Jq90Ni B1cR/lSmDsi73FOJdC3mpTGkrQXACu9tHa4poN3fkQ== X-Google-Smtp-Source: APXvYqyGgnRzC/YRie64niefMvgawW6RK21yPqM0zialvJFEd4a6Z7iuhn/AjgaPZsvq+/fqUfeR5iVlCDr+6w9vWVk= X-Received: by 2002:a05:6830:2308:: with SMTP id u8mr5018538ote.2.1574193265740; Tue, 19 Nov 2019 11:54:25 -0800 (PST) MIME-Version: 1.0 References: <20191114180303.66955-1-elver@google.com> <20191114180303.66955-2-elver@google.com> <1574191653.9585.6.camel@lca.pw> In-Reply-To: <1574191653.9585.6.camel@lca.pw> From: Marco Elver Date: Tue, 19 Nov 2019 20:54:14 +0100 Message-ID: Subject: Re: [PATCH v4 01/10] kcsan: Add Kernel Concurrency Sanitizer infrastructure To: Qian Cai Cc: LKMM Maintainers -- Akira Yokosawa , Alan Stern , Alexander Potapenko , Andrea Parri , Andrey Konovalov , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Boqun Feng , Borislav Petkov , Daniel Axtens , Daniel Lustig , Dave Hansen , David Howells , Dmitry Vyukov , "H. Peter Anvin" , Ingo Molnar , Jade Alglave , Joel Fernandes , Jonathan Corbet , Josh Poimboeuf , Luc Maranget , Mark Rutland , Nicholas Piggin , "Paul E. McKenney" , Peter Zijlstra , Thomas Gleixner , Will Deacon , Eric Dumazet , kasan-dev , linux-arch , "open list:DOCUMENTATION" , linux-efi@vger.kernel.org, Linux Kbuild mailing list , LKML , Linux Memory Management List , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 19 Nov 2019 at 20:27, Qian Cai wrote: > > On Thu, 2019-11-14 at 19:02 +0100, 'Marco Elver' via kasan-dev wrote: > > > +menuconfig KCSAN > > + bool "KCSAN: watchpoint-based dynamic data race detector" > > + depends on HAVE_ARCH_KCSAN && !KASAN && STACKTRACE > > "!KASAN" makes me sorrow. What's problem of those two? Both of them instrument memory accesses, and gcc doesn't let us combine '-fsanitize=3D{kernel-,}address' and '-fsanitize=3Dthread'. > cc1: error: =E2=80=98-fsanitize=3Daddress=E2=80=99 and =E2=80=98-fsanitiz= e=3Dkernel-address=E2=80=99 are incompatible with =E2=80=98-fsanitize=3Dthr= ead=E2=80=99 In principle, it may be possible: - either by updating the compiler, which we want to avoid because we'd have to convince gcc and clang to do this; I can see this being infeasible because the compiler needs to become aware (somehow propagate in the IR) of what is ASAN inline-instrumentation and what is TSAN instrumentation and not emit recursive instrumentation. - or somehow merging the instrumentation, but, IMHO this is probably a really bad idea for various other reasons (complexity, performance, stability, etc.). Regardless of approach, my guess is that the complexity outweighs any benefits this may provide in the end. Not only would a hypothetical kernel that combines these be extremely slow, it'd also diminish the practical value because testing and finding bugs would also be impaired due to performance. Thanks, -- Marco From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marco Elver Subject: Re: [PATCH v4 01/10] kcsan: Add Kernel Concurrency Sanitizer infrastructure Date: Tue, 19 Nov 2019 20:54:14 +0100 Message-ID: References: <20191114180303.66955-1-elver@google.com> <20191114180303.66955-2-elver@google.com> <1574191653.9585.6.camel@lca.pw> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1574191653.9585.6.camel@lca.pw> Sender: linux-kernel-owner@vger.kernel.org To: Qian Cai Cc: LKMM Maintainers -- Akira Yokosawa , Alan Stern , Alexander Potapenko , Andrea Parri , Andrey Konovalov , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Boqun Feng , Borislav Petkov , Daniel Axtens , Daniel Lustig , Dave Hansen , David Howells , Dmitry Vyukov , "H. Peter Anvin" , Ingo Molnar , Jade Alglave , Joel Fernandes , Jonathan Corbet List-Id: linux-arch.vger.kernel.org On Tue, 19 Nov 2019 at 20:27, Qian Cai wrote: > > On Thu, 2019-11-14 at 19:02 +0100, 'Marco Elver' via kasan-dev wrote: > > > +menuconfig KCSAN > > + bool "KCSAN: watchpoint-based dynamic data race detector" > > + depends on HAVE_ARCH_KCSAN && !KASAN && STACKTRACE > > "!KASAN" makes me sorrow. What's problem of those two? Both of them instrument memory accesses, and gcc doesn't let us combine '-fsanitize=3D{kernel-,}address' and '-fsanitize=3Dthread'. > cc1: error: =E2=80=98-fsanitize=3Daddress=E2=80=99 and =E2=80=98-fsanitiz= e=3Dkernel-address=E2=80=99 are incompatible with =E2=80=98-fsanitize=3Dthr= ead=E2=80=99 In principle, it may be possible: - either by updating the compiler, which we want to avoid because we'd have to convince gcc and clang to do this; I can see this being infeasible because the compiler needs to become aware (somehow propagate in the IR) of what is ASAN inline-instrumentation and what is TSAN instrumentation and not emit recursive instrumentation. - or somehow merging the instrumentation, but, IMHO this is probably a really bad idea for various other reasons (complexity, performance, stability, etc.). Regardless of approach, my guess is that the complexity outweighs any benefits this may provide in the end. Not only would a hypothetical kernel that combines these be extremely slow, it'd also diminish the practical value because testing and finding bugs would also be impaired due to performance. Thanks, -- Marco 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,URIBL_BLOCKED,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 13427C43215 for ; Tue, 19 Nov 2019 19:54:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CB49B22469 for ; Tue, 19 Nov 2019 19:54:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="oURkgRgG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB49B22469 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 6987C6B0003; Tue, 19 Nov 2019 14:54:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 66FE86B0006; Tue, 19 Nov 2019 14:54:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 586846B0008; Tue, 19 Nov 2019 14:54:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id 431536B0003 for ; Tue, 19 Nov 2019 14:54:28 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id D8A6F5847 for ; Tue, 19 Nov 2019 19:54:27 +0000 (UTC) X-FDA: 76174078974.14.clock93_26e2280463f23 X-HE-Tag: clock93_26e2280463f23 X-Filterd-Recvd-Size: 5662 Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Tue, 19 Nov 2019 19:54:27 +0000 (UTC) Received: by mail-ot1-f68.google.com with SMTP id 1so2191401otk.1 for ; Tue, 19 Nov 2019 11:54:26 -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=EhLUhFf+dWrZRS+as37pEKZIEswUZkBGb2xI++P3+j8=; b=oURkgRgGWUkSxDSZ1GZcf9JKZThTVFiPnKTPYV6+NAQo4qwintbC2XWKkuqirZuVFU bTYZKRscOUCeu16ZKaeZ3gXmUectwJqraAkzc8IBVgzlI8PbblowyxH6P3Ln12UZk9iO Pl0kfXxMBXKjXj6d8JggILhmHIA8f4ZCcFz6nGlkz7lVmiWjRLK+0aGRrkffeyuCuNkI 0zslGM9F/hSRR4n8JF2dvLzZiZ64O/OcPnSgVvg+FuFKwOq/W9YtVItB909hWO3GwyqT +0ZUwJKbggzqgLthIVoIszbE1Prv8ek/hgwno+wjPrrY7IKe9Gu3nZy0IvutjK5EGayQ o9iA== 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=EhLUhFf+dWrZRS+as37pEKZIEswUZkBGb2xI++P3+j8=; b=QeGAlbRUvuTwF/p5fpBhezOCv7ezEzd7rlGjpymeSxH+KPfWOZ+Jxl4OPX6MVUzYw3 NjR4/LlG3Zix7EF/4NFGueap5dlCznjlEXg6zqxLdZj2szLU95yJ5IgEXsrv7DaPH36z JwjzHY3u6YSu8leuMqXfiH3Tw4tR8J1BSPkWWr/AEGl/sRQWAP6wcM/sgcTIWi/BKWDV cOD/FlztFrmIAI/2vPy/ggkeaGxapo/n5Hs+8yNwmPwsdEknCGTLv/ymwZnMFvIH9UPE AqF8s24dk503Z2AFz7ewBoHJOA0HPTyLPw6a64TQ9d4yPnNYNT170EUxUOZPMvZsfIBu 6mXw== X-Gm-Message-State: APjAAAUsyN3dOWHsKrE57QJdzu5Xx9nSFjZYN05VEc+BAIa39yAVJAXI L9mK7Day1ZuZ/T0X0rWMjUtiWDGSo+hqrRbemrJswA== X-Google-Smtp-Source: APXvYqyGgnRzC/YRie64niefMvgawW6RK21yPqM0zialvJFEd4a6Z7iuhn/AjgaPZsvq+/fqUfeR5iVlCDr+6w9vWVk= X-Received: by 2002:a05:6830:2308:: with SMTP id u8mr5018538ote.2.1574193265740; Tue, 19 Nov 2019 11:54:25 -0800 (PST) MIME-Version: 1.0 References: <20191114180303.66955-1-elver@google.com> <20191114180303.66955-2-elver@google.com> <1574191653.9585.6.camel@lca.pw> In-Reply-To: <1574191653.9585.6.camel@lca.pw> From: Marco Elver Date: Tue, 19 Nov 2019 20:54:14 +0100 Message-ID: Subject: Re: [PATCH v4 01/10] kcsan: Add Kernel Concurrency Sanitizer infrastructure To: Qian Cai Cc: LKMM Maintainers -- Akira Yokosawa , Alan Stern , Alexander Potapenko , Andrea Parri , Andrey Konovalov , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Boqun Feng , Borislav Petkov , Daniel Axtens , Daniel Lustig , Dave Hansen , David Howells , Dmitry Vyukov , "H. Peter Anvin" , Ingo Molnar , Jade Alglave , Joel Fernandes , Jonathan Corbet , Josh Poimboeuf , Luc Maranget , Mark Rutland , Nicholas Piggin , "Paul E. McKenney" , Peter Zijlstra , Thomas Gleixner , Will Deacon , Eric Dumazet , kasan-dev , linux-arch , "open list:DOCUMENTATION" , linux-efi@vger.kernel.org, Linux Kbuild mailing list , LKML , Linux Memory Management List , "the arch/x86 maintainers" 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 Tue, 19 Nov 2019 at 20:27, Qian Cai wrote: > > On Thu, 2019-11-14 at 19:02 +0100, 'Marco Elver' via kasan-dev wrote: > > > +menuconfig KCSAN > > + bool "KCSAN: watchpoint-based dynamic data race detector" > > + depends on HAVE_ARCH_KCSAN && !KASAN && STACKTRACE > > "!KASAN" makes me sorrow. What's problem of those two? Both of them instrument memory accesses, and gcc doesn't let us combine '-fsanitize=3D{kernel-,}address' and '-fsanitize=3Dthread'. > cc1: error: =E2=80=98-fsanitize=3Daddress=E2=80=99 and =E2=80=98-fsanitiz= e=3Dkernel-address=E2=80=99 are incompatible with =E2=80=98-fsanitize=3Dthr= ead=E2=80=99 In principle, it may be possible: - either by updating the compiler, which we want to avoid because we'd have to convince gcc and clang to do this; I can see this being infeasible because the compiler needs to become aware (somehow propagate in the IR) of what is ASAN inline-instrumentation and what is TSAN instrumentation and not emit recursive instrumentation. - or somehow merging the instrumentation, but, IMHO this is probably a really bad idea for various other reasons (complexity, performance, stability, etc.). Regardless of approach, my guess is that the complexity outweighs any benefits this may provide in the end. Not only would a hypothetical kernel that combines these be extremely slow, it'd also diminish the practical value because testing and finding bugs would also be impaired due to performance. Thanks, -- Marco