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 3BC40C432C0 for ; Tue, 19 Nov 2019 21:54:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1057A223E4 for ; Tue, 19 Nov 2019 21:54:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="os/9/wpF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727452AbfKSVyC (ORCPT ); Tue, 19 Nov 2019 16:54:02 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:33005 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727403AbfKSVyB (ORCPT ); Tue, 19 Nov 2019 16:54:01 -0500 Received: by mail-ot1-f67.google.com with SMTP id u13so19366384ote.0 for ; Tue, 19 Nov 2019 13:54:01 -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; bh=xwQvEr0/UaVV1k90qxcSpFl3vFq94C3DTr9L5ipVOwI=; b=os/9/wpFP/DXclPEjwrDUzXZ9xZyYOLNYumwPQAx6DyFBIR7SoxEqKwNn+/IZhR//X OQOeRncPuE1vhO2moGvPoo7z6/z3zTRs91p3NkWjOK3lktd5iMvMjjFDe19mGrjssLPS zmmzHsKAaRO/a/uzddjHH/kpp2a3Rz2HX47MN7hGP8BL5NJEV0SKqDceVCAlwP4KAUz3 brpZdGqYvdc1o2yKVBKQgsX5jRGCrki9za3mxu8k5xR82ifHBeu43F7TGh7R70va38Ns vrNtgb7acdZidnXSx39yPOh3nrgilOQsv6q8diSKlHIdchPOifk+39wxRB9wr4KJgIql CzFQ== 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; bh=xwQvEr0/UaVV1k90qxcSpFl3vFq94C3DTr9L5ipVOwI=; b=BpWTBY+jKOCZhB7Jqu+njjSwWiiRbxbOq9JNmq2lEDtIgD0r8bGoJG4/+LaaDJ+r4j HOzOha+PlqkLjMa/nuTtjCWD4iN0P9QWdCx123OKqgZ1QXfCVW9pRacELOswye7oGKz0 jJ+NHimw4VNULRitkSV3ujKI2aCFn2AMyStE7G31l43xYFflaoXJbSeqUMpnE0fChpPg J5qCo0+nH/1N7dyanPDFafbQ3QQQVPHJv7yQLlVklF9oYEzc0Fd4QkLcYJM97+1dLlwB yhovnwUkfvLhs2jRNNNs2bXujJ/f+9c5d/EBYOCSmjYTsoKtnyT7vs7BWiDYxKduHfjd VXpw== X-Gm-Message-State: APjAAAVIk5nU2+SiKb+SmNfAwfm0grFWqxPdRz9v33pf8JDod/I4wvSQ eGTASW84CokdZAq5mhlDyJgR38+h7T1SlIyK+OAj7g== X-Google-Smtp-Source: APXvYqz2fsoAggh7I5N4oqb965IJ4kPem0JLzhQ1wxS9dVs2sFp6YDXQH7OhcFkNUVDUWie4TDvvMj1XJov8Z8A+PIE= X-Received: by 2002:a9d:82e:: with SMTP id 43mr5680239oty.23.1574200440363; Tue, 19 Nov 2019 13:54:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Tue, 19 Nov 2019 22:53:48 +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" 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 22:42, Qian Cai wrote: > > > > > On Nov 19, 2019, at 2:54 PM, Marco Elver wrote: > > > > 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. > > On the other hand, it is valuable for distros to be able to select both for the debug kernel variant. Performance is usually not a major concern over there and could be migrated by other means like selecting powerful systems etc. Fair enough. However, right now none of gcc nor clang would support this. It is something to revisit in future, but is certainly not something that can trivially be resolved. 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 22:53:48 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: 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 22:42, Qian Cai wrote: > > > > > On Nov 19, 2019, at 2:54 PM, Marco Elver wrote: > > > > 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. > > On the other hand, it is valuable for distros to be able to select both for the debug kernel variant. Performance is usually not a major concern over there and could be migrated by other means like selecting powerful systems etc. Fair enough. However, right now none of gcc nor clang would support this. It is something to revisit in future, but is certainly not something that can trivially be resolved. 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 5392DC43215 for ; Tue, 19 Nov 2019 21:54:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0EA49222DF for ; Tue, 19 Nov 2019 21:54:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="os/9/wpF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0EA49222DF 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 AC94F6B0003; Tue, 19 Nov 2019 16:54:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A52346B0006; Tue, 19 Nov 2019 16:54:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91A7C6B0007; Tue, 19 Nov 2019 16:54:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0130.hostedemail.com [216.40.44.130]) by kanga.kvack.org (Postfix) with ESMTP id 776116B0003 for ; Tue, 19 Nov 2019 16:54:02 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 3C0A8180AD80F for ; Tue, 19 Nov 2019 21:54:02 +0000 (UTC) X-FDA: 76174380324.03.paper20_4047a643f0648 X-HE-Tag: paper20_4047a643f0648 X-Filterd-Recvd-Size: 4959 Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Tue, 19 Nov 2019 21:54:01 +0000 (UTC) Received: by mail-ot1-f68.google.com with SMTP id z25so19375808oti.5 for ; Tue, 19 Nov 2019 13:54:01 -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; bh=xwQvEr0/UaVV1k90qxcSpFl3vFq94C3DTr9L5ipVOwI=; b=os/9/wpFP/DXclPEjwrDUzXZ9xZyYOLNYumwPQAx6DyFBIR7SoxEqKwNn+/IZhR//X OQOeRncPuE1vhO2moGvPoo7z6/z3zTRs91p3NkWjOK3lktd5iMvMjjFDe19mGrjssLPS zmmzHsKAaRO/a/uzddjHH/kpp2a3Rz2HX47MN7hGP8BL5NJEV0SKqDceVCAlwP4KAUz3 brpZdGqYvdc1o2yKVBKQgsX5jRGCrki9za3mxu8k5xR82ifHBeu43F7TGh7R70va38Ns vrNtgb7acdZidnXSx39yPOh3nrgilOQsv6q8diSKlHIdchPOifk+39wxRB9wr4KJgIql CzFQ== 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; bh=xwQvEr0/UaVV1k90qxcSpFl3vFq94C3DTr9L5ipVOwI=; b=k1T803ATMbGkTLWVM/eRUJWS6wUOCugSd4KKT2l8Vj6+aNXRqJxOdW51YQWjkCK4hB kjIFAsMOUyZrcaCACK+3OLmBIRNmKTcjTeKSFAbafw4XTey6m/wqJjprwPiQLR+Ha1c2 snFCoCeTWn8wqHGnToIr+gDmMoEqqNpLNyUKRZT9sk0oHyuUt6ld5FV2xDGfgfjxFV8S M5oLsA2Idp+EsFfkM9F/lxEsifUzWcOcIhtYQPRhyU9tnYs6Hu/MCqIXanThVqNqAQin CjidI8GsFn+C+h8pfTgqRp7S9odx9AYUZa55mKMupwdAvvMxtFVd971h4d5cc458FWQo LCrg== X-Gm-Message-State: APjAAAVjaQTz1lpC7ctXn67uI1PUEsz7v3W/4/TAuClCsVe6JuLxUVM8 l3m/suhjAX3kVMiwEvk4ejeyi+eFCmnpv0vYn6nhTA== X-Google-Smtp-Source: APXvYqz2fsoAggh7I5N4oqb965IJ4kPem0JLzhQ1wxS9dVs2sFp6YDXQH7OhcFkNUVDUWie4TDvvMj1XJov8Z8A+PIE= X-Received: by 2002:a9d:82e:: with SMTP id 43mr5680239oty.23.1574200440363; Tue, 19 Nov 2019 13:54:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Tue, 19 Nov 2019 22:53:48 +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" 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 22:42, Qian Cai wrote: > > > > > On Nov 19, 2019, at 2:54 PM, Marco Elver wrote: > > > > 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. > > On the other hand, it is valuable for distros to be able to select both for the debug kernel variant. Performance is usually not a major concern over there and could be migrated by other means like selecting powerful systems etc. Fair enough. However, right now none of gcc nor clang would support this. It is something to revisit in future, but is certainly not something that can trivially be resolved. Thanks, -- Marco