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 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).