Messages in this thread Patch in this message | | | Subject | Re: UBSAN: run-time undefined behavior sanity checker | From | Andrey Ryabinin <> | Date | Mon, 25 Jan 2016 17:03:48 +0300 |
| |
On 01/22/2016 08:00 PM, Dave Jones wrote: > On Fri, Jan 22, 2016 at 07:43:55PM +0300, Andrey Ryabinin wrote: > > On 01/22/2016 08:15 AM, Dave Jones wrote: > > > On Thu, Jan 21, 2016 at 08:57:17PM +0000, Linux Kernel wrote: > > > > Web: https://git.kernel.org/torvalds/c/c6d308534aef6c99904bf5862066360ae067abc4 > > > > Commit: c6d308534aef6c99904bf5862066360ae067abc4 > > > > Parent: 68920c973254c5b71a684645c5f6f82d6732c5d6 > > > > Refname: refs/heads/master > > > > Author: Andrey Ryabinin <aryabinin@virtuozzo.com> > > > > AuthorDate: Wed Jan 20 15:00:55 2016 -0800 > > > > Committer: Linus Torvalds <torvalds@linux-foundation.org> > > > > CommitDate: Wed Jan 20 17:09:18 2016 -0800 > > > > > > > > UBSAN: run-time undefined behavior sanity checker > > > > > > > > UBSAN uses compile-time instrumentation to catch undefined behavior > > > > (UB). Compiler inserts code that perform certain kinds of checks before > > > > operations that could cause UB. If check fails (i.e. UB detected) > > > > __ubsan_handle_* function called to print error message. > > > > > > > > So the most of the work is done by compiler. This patch just implements > > > > ubsan handlers printing errors. > > > > > > > > GCC has this capability since 4.9.x [1] (see -fsanitize=undefined > > > > option and its suboptions). > > > > However GCC 5.x has more checkers implemented [2]. > > > > Article [3] has a bit more details about UBSAN in the GCC. > > > > > > If I enable this and CONFIG_UBSAN_ALIGNMENT, the kernel doesn't boot, > > > and hangs really early (pretty much as soon as I hit return in grub) > > > far too early for serial console or even tty output. > > > > > > Compiler is debian unstable's 5.3.1 20160114 > > > > > > I don't know if this is worth chasing down, I chose to just disable it, > > > but figured I'd post in case other people stumble across the same issue. > > > > > > > Likely caused by unaligned access in very early code, which ends up in too early printk() call. > > You could try to disable instrumentation (UBSAN_SANITIZE := n) in early code. > > > > Be aware that CONFIG_UBSAN_ALIGNMENT causes a *lot* of spam in dmesg. Since x86 supports unaligned > > accesses, the significant amount of that spam just a false-positive reports. > > So disabling that option fixed booting on one machine, but every other I've > tried it on hangs the same way, really early. Any thoughts on how to chase this down ? >
Try to disable instrumentation for early code, like in the patch bellow. Also send me you .config please. Perhaps I will be able to reproduce this.
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index b1b78ff..d39a954 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -20,6 +20,8 @@ KASAN_SANITIZE_head$(BITS).o := n KASAN_SANITIZE_dumpstack.o := n KASAN_SANITIZE_dumpstack_$(BITS).o := n +UBSAN_SANITIZE := n + CFLAGS_irq.o := -I$(src)/../include/asm/trace obj-y := process_$(BITS).o signal.o
| |