From: Guenter Roeck <linux@roeck-us.net>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: Crash in -next due to 'objtool: Improve detection of BUG() and other dead ends'
Date: Mon, 27 Feb 2017 15:23:28 -0800 [thread overview]
Message-ID: <20170227232328.GA1604@roeck-us.net> (raw)
In-Reply-To: <20170227222114.p6vdugfmfjfprt47@treble>
Hi Josh,
On Mon, Feb 27, 2017 at 04:21:14PM -0600, Josh Poimboeuf wrote:
> On Mon, Feb 27, 2017 at 12:59:23PM -0800, Guenter Roeck wrote:
> > Hi,
> >
> > my qemu tests for mips64 in -next fail as follows.
> >
> > ...
> > VFS: Mounted root (ext3 filesystem) on device 8:0.
> > Freeing unused kernel memory: 304K
> > This architecture does not have kernel memory protection.
> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a
> >
> > ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a
> >
> > There is no symbol traceback, and I don't see any other (obvious) error
> > message. bisect points to commit 'objtool: Improve detection of BUG()
> > and other dead ends'; reverting that patch fixes the problem.
> > Bisect log is attached below.
> >
> > The script used to run the test as well as the root file system is available
> > at https://github.com/groeck/linux-build-test/tree/master/rootfs/mips64
> >
> > A complete log is available at
> > http://kerneltests.org/builders/qemu-mips64-next/builds/592/steps/qemubuildcommand/logs/stdio
>
> Hi Guenter,
>
> This failure doesn't make much sense. Objtool (and the reported bad
> patch) are x86-only and should have nothing to do with mips64. Would it
> be possible for you to double check the error?
>
I already did; after all, bisect points to the patch, and reverting it fixes
the problem. After looking into the patch, I concluded that the following
might help.
-#define unreachable() annotate_unreachable(); __builtin_unreachable()
+#define unreachable() do { annotate_unreachable(); __builtin_unreachable(); } while (0)
and it does ...
> Otherwise I could try to recreate. Do you have a recommendation for a
> mips cross-compiler? (preferably something that's already built and that
> might work on Fedora)
>
I use gcc 4.9.0 from
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/
Guenter
next prev parent reply other threads:[~2017-02-28 1:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-27 20:59 Crash in -next due to 'objtool: Improve detection of BUG() and other dead ends' Guenter Roeck
2017-02-27 22:21 ` Josh Poimboeuf
2017-02-27 23:23 ` Guenter Roeck [this message]
2017-02-28 0:43 ` Josh Poimboeuf
2017-02-28 4:21 ` [PATCH] objtool: enclose contents of unreachable() macro in a block Josh Poimboeuf
2017-02-28 6:49 ` [tip:core/urgent] objtool: Enclose " tip-bot for Josh Poimboeuf
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=20170227232328.GA1604@roeck-us.net \
--to=linux@roeck-us.net \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.