On Tue, Nov 19, 2019 at 08:05:45PM +0100, Marco Elver wrote: > On Tue, 19 Nov 2019 at 20:02, Qian Cai <cai@xxxxxx> wrote: > > > > On Tue, 2019-11-19 at 19:34 +0100, 'Marco Elver' via kasan-dev wrote: > > > 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@xxxxxxxxxxxxx> 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. > > > > Both option #1 and #2 sounds quite unfortunate, as UBSAN is quite valuable for > > debugging. Hence, it is desire to make both work at the same time. > > Apologies, I think I was a bit unclear with #1. For #1, this just > means that UBSAN is being disabled for the KCSAN runtime and > vice-versa. All other parts of the kernel are still instrumented with > both. > > See here: https://lore.kernel.org/linux-next/20191119185742.GB68739@xxxxxxxxxx/ Huh. This somehow got stuck into my non-urgent email. No idea why. Anyway, I applied and pushed it out on the kcsan branch of -rcu. Thanx, Paul
