lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 27 Feb 2017 15:23:28 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: Crash in -next due to 'objtool: Improve detection of BUG() and
 other dead ends'

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

Powered by blists - more mailing lists