[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNOJdWi6i+2Nn70UQDvF0a0pQTVVye7CTTJgqOHa3UmHMQ@mail.gmail.com>
Date: Tue, 19 Nov 2019 22:53:48 +0100
From: Marco Elver <elver@...gle.com>
To: Qian Cai <cai@....pw>
Cc: LKMM Maintainers -- Akira Yokosawa <akiyks@...il.com>,
Alan Stern <stern@...land.harvard.edu>,
Alexander Potapenko <glider@...gle.com>,
Andrea Parri <parri.andrea@...il.com>,
Andrey Konovalov <andreyknvl@...gle.com>,
Andy Lutomirski <luto@...nel.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
Boqun Feng <boqun.feng@...il.com>,
Borislav Petkov <bp@...en8.de>, Daniel Axtens <dja@...ens.net>,
Daniel Lustig <dlustig@...dia.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
David Howells <dhowells@...hat.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Jade Alglave <j.alglave@....ac.uk>,
Joel Fernandes <joel@...lfernandes.org>,
Jonathan Corbet <corbet@....net>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Luc Maranget <luc.maranget@...ia.fr>,
Mark Rutland <Mark.Rutland@....com>,
Nicholas Piggin <npiggin@...il.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Will Deacon <will@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
kasan-dev <kasan-dev@...glegroups.com>,
linux-arch <linux-arch@...r.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
linux-efi@...r.kernel.org,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH v4 01/10] kcsan: Add Kernel Concurrency Sanitizer infrastructure
On Tue, 19 Nov 2019 at 22:42, Qian Cai <cai@....pw> wrote:
>
>
>
> > On Nov 19, 2019, at 2:54 PM, Marco Elver <elver@...gle.com> 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
Powered by blists - more mailing lists