[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160122170053.GB30299@codemonkey.org.uk>
Date: Fri, 22 Jan 2016 12:00:53 -0500
From: Dave Jones <davej@...emonkey.org.uk>
To: Andrey Ryabinin <aryabinin@...tuozzo.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: UBSAN: run-time undefined behavior sanity checker
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@...tuozzo.com>
> > > AuthorDate: Wed Jan 20 15:00:55 2016 -0800
> > > Committer: Linus Torvalds <torvalds@...ux-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 ?
Dave
Powered by blists - more mailing lists