On Thu, 21 May 2020 at 00:17, Borislav Petkov <[email protected]> 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 <[email protected]> > > AuthorDate: Mon, 11 May 2020 21:41:49 +01:00 > > Committer: Thomas Gleixner <[email protected]> > > 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 <[email protected]> > > Signed-off-by: Thomas Gleixner <[email protected]> > > Acked-by: Peter Zijlstra (Intel) <[email protected]> > > Cc: Marco Elver <[email protected]> > > Link: https://lkml.kernel.org/r/[email protected] > > 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/[email protected]/ Thanks, -- Marco
