[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNPsEMF8qq4qHoJEDb8mi211QzXODvnakh2fj3BOw+56MQ@mail.gmail.com>
Date: Thu, 21 May 2020 00:30:39 +0200
From: Marco Elver <elver@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Will Deacon <will@...nel.org>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-tip-commits@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>, x86 <x86@...nel.org>
Subject: Re: [tip: locking/kcsan] READ_ONCE: Use data_race() to avoid KCSAN instrumentation
On Thu, 21 May 2020 at 00:17, Borislav Petkov <bp@...en8.de> wrote:
>
> Hi,
>
> On Tue, May 12, 2020 at 02:36:53PM -0000, tip-bot2 for Will Deacon wrote:
> > The following commit has been merged into the locking/kcsan branch of tip:
> >
> > Commit-ID: cdd28ad2d8110099e43527e96d059c5639809680
> > Gitweb: https://git.kernel.org/tip/cdd28ad2d8110099e43527e96d059c5639809680
> > Author: Will Deacon <will@...nel.org>
> > AuthorDate: Mon, 11 May 2020 21:41:49 +01:00
> > Committer: Thomas Gleixner <tglx@...utronix.de>
> > CommitterDate: Tue, 12 May 2020 11:04:17 +02:00
> >
> > READ_ONCE: Use data_race() to avoid KCSAN instrumentation
> >
> > Rather then open-code the disabling/enabling of KCSAN across the guts of
> > {READ,WRITE}_ONCE(), defer to the data_race() macro instead.
> >
> > Signed-off-by: Will Deacon <will@...nel.org>
> > Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> > Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> > Cc: Marco Elver <elver@...gle.com>
> > Link: https://lkml.kernel.org/r/20200511204150.27858-18-will@kernel.org
>
> so this commit causes a kernel build slowdown depending on the .config
> of between 50% and over 100%. I just bisected locking/kcsan and got
>
> NOT_OK: cdd28ad2d811 READ_ONCE: Use data_race() to avoid KCSAN instrumentation
> OK: 88f1be32068d kcsan: Rework data_race() so that it can be used by READ_ONCE()
>
> with a simple:
>
> $ git clean -dqfx && mk defconfig
> $ time make -j<NUM_CORES+1>
>
> I'm not even booting the kernels - simply checking out the above commits
> and building the target kernels. I.e., something in that commit is
> making gcc go nuts in the compilation phases.
This should be fixed when the series that includes this commit is applied:
https://lore.kernel.org/lkml/20200515150338.190344-9-elver@google.com/
Thanks,
-- Marco
Powered by blists - more mailing lists