linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	"Paul E. McKenney" <paulmck@kernel.org>
Subject: Re: linux-next: Tree for Nov 19 (kcsan)
Date: Tue, 19 Nov 2019 19:34:07 +0100	[thread overview]
Message-ID: <20191119183407.GA68739@google.com> (raw)
In-Reply-To: <fb7e25d8-aba4-3dcf-7761-cb7ecb3ebb71@infradead.org>

On Tue, 19 Nov 2019, Randy Dunlap wrote:

> On 11/19/19 8:12 AM, Marco Elver wrote:
> > On Tue, 19 Nov 2019 at 16:11, Randy Dunlap <rdunlap@infradead.org> wrote:
> >>
> >> On 11/19/19 12:46 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Changes since 20191118:
> >>>
> >>
> >> on x86_64:
> >>
> >> It seems that this function can already be known by the compiler as a
> >> builtin:
> >>
> >> ../kernel/kcsan/core.c:619:6: warning: conflicting types for built-in function ‘__tsan_func_exit’ [-Wbuiltin-declaration-mismatch]
> >>  void __tsan_func_exit(void)
> >>       ^~~~~~~~~~~~~~~~
> >>
> >>
> >> $ gcc --version
> >> gcc (SUSE Linux) 7.4.1 20190905 [gcc-7-branch revision 275407]
> > 
> > Interesting. Could you share the .config? So far I haven't been able
> > to reproduce.
> 
> Sure, it's attached.

Thanks, the config did the trick, even for gcc 9.0.0.

The problem is CONFIG_UBSAN=y. We haven't explicitly disallowed it like
with KASAN. In principle there should be nothing wrong with KCSAN+UBSAN.

There are 3 options:
1. Just disable UBSAN for KCSAN, and also disable KCSAN for UBSAN.
2. Restrict the config to not allow combining KCSAN and UBSAN.
3. Leave things as-is.

Option 1 probably makes most sense, and I'll send a patch for that
unless there are major objections.

> > I can get the warning if I manually add -fsanitize=thread to flags for
> > kcsan/core.c (but normally disabled via KCSAN_SANITIZE := n). If
> > possible could you also share the output of `make V=1` for
> > kcsan/core.c?
> 
> here:

>   gcc -Wp,-MD,kernel/kcsan/.core.o.d  -nostdinc -isystem /usr/lib64/gcc/x86_64-suse-linux/7/include -I../arch/x86/include -I./arch/x86/include/generated -I../include -I./include -I../arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I../include/uapi -I./include/generated/uapi -include ../include/linux/kconfig.h -include ../include/linux/compiler_types.h -D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -Wno-sign-compare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fno-conserve-stack -fno-stack-protector  -fprofile-arcs -ftest-coverage -fno-tree-loop-im -Wno-maybe-uninitialized    -fsanitize=shift  -fsanitize=integer-divide-by-zero  -fsanitize=unreachable  -fsanitize=signed-integer-overflow  -fsanitize=bounds  -fsanitize=object-size  -fsanitize=bool  -fsanitize=enum  -Wno-maybe-uninitialized   -I ../kernel/kcsan -I ./kernel/kcsan    -DKBUILD_BASENAME='"core"' -DKBUILD_MODNAME='"core"' -c -o kernel/kcsan/core.o ../kernel/kcsan/core.c
> ../kernel/kcsan/core.c:619:6: warning: conflicting types for built-in function ‘__tsan_func_exit’ [-Wbuiltin-declaration-mismatch]

Adding '-fsanitize=<anything>' seems to make gcc think that these are
builtins. So this is partially also a gcc problem, but if we disable all
sanitizers with the runtime, then this goes away.

Thanks,
-- Marco

  reply	other threads:[~2019-11-19 18:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19  8:46 linux-next: Tree for Nov 19 Stephen Rothwell
2019-11-19 15:11 ` linux-next: Tree for Nov 19 (kcsan) Randy Dunlap
2019-11-19 16:12   ` Marco Elver
2019-11-19 16:50     ` Randy Dunlap
2019-11-19 18:34       ` Marco Elver [this message]
2019-11-19 18:57         ` [PATCH -next] kcsan, ubsan: Make KCSAN+UBSAN work together Marco Elver
2019-11-19 20:16           ` Paul E. McKenney
2019-11-19 21:07           ` Randy Dunlap
2019-11-19 21:17             ` Paul E. McKenney
2019-11-19 19:02         ` linux-next: Tree for Nov 19 (kcsan) Qian Cai
2019-11-19 19:05           ` Marco Elver
2019-11-19 20:14             ` Paul E. McKenney
2019-11-19 15:13 ` linux-next: Tree for Nov 19 (bpf) Randy Dunlap
2019-11-27 23:45   ` linux-next: Tree for Nov 19 (bpf/btf) Randy Dunlap
2019-11-19 15:33 ` linux-next: Tree for Nov 19 (i915) Randy Dunlap
2019-11-20 16:15   ` [Intel-gfx] " Jani Nikula
2019-11-20 16:56     ` Chris Wilson
2019-11-20 21:54       ` Randy Dunlap
2019-11-19 15:38 ` linux-next: Tree for Nov 19 (objtool) Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191119183407.GA68739@google.com \
    --to=elver@google.com \
    --cc=dvyukov@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).