linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
To: Meelis Roos <mroos@linux.ee>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: 3.13: BUG: unable to handle kernel paging request at 00000000b4343e88
Date: Fri, 31 Jan 2014 16:50:52 +0100	[thread overview]
Message-ID: <52EBC65C.5020404@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.SOC.1.00.1401292242390.12718@math.ut.ee>

On 29.01.2014 21:44, Meelis Roos wrote:
>>> I do not get very far - it still crashes on startuo. PNG attached.
>>
>> I tried to reproduce this behavior a couple of times with no success.
>> Could you post your kernel configuration? I've also modified the
>> debugging patch to ensure that the gcov_info structure passed to
>> gcov_init() is no longer accessed beyond displaying the first 64
>> bytes. If you could apply this and send dmesg output, this might
>> hopefully provide a clue as to why the kernel cannot handle these
>> data structures correctly.
> 
> This patch makes it boot. dmesg and config are below.

Using your config I was able to reproduce the crash and locate the
cause. Commit d61931d89b, "x86: Add optimized popcnt variants" adds
option -fcall-saved-rdi to the compile flags of lib/hweight.c when
compiling for x86_64. Together with options --coverage and -O2, this
results in a broken constructor being generated by GCC for this object
file which in turn causes __gcov_init() to overwrite random memory
locations (a mutex in your case).

I tried to report this as a bug against GCC [1] but the report was
closed as invalid citing the following section from GCC documentation
for -fcall-saved-*:

  It is an error to use this flag with the frame pointer or stack
  pointer. Use of this flag for other registers that have fixed
  pervasive roles in the machine's execution model produces disastrous
  results.

Apparently %rdi is the first parameter register on x86_64 and therefore
qualifies as having a fixed pervasive role.

Digging deeper into the history of commit d61931d89b I found a
discussion [2] indicating that the use of -fcall-saved-rdi is not
strictly necessary with a dummy inline asm constraint being a potential
alternative. I've added Borislav Petkov and H. Peter Anvin who have been
involved in the discussion of this commit to CC:, hoping that they might
be able to provide a solution to this problem.


[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60008
[2] http://lkml.org/lkml/2010/2/23/24

-- 
Peter Oberparleiter
Linux on System z Development - IBM Germany


  parent reply	other threads:[~2014-01-31 15:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-21 10:34 3.13: BUG: unable to handle kernel paging request at 00000000b4343e88 Meelis Roos
2014-01-21 22:10 ` Andrew Morton
2014-01-22 15:33   ` Meelis Roos
2014-01-24 13:47     ` Peter Oberparleiter
2014-01-24 20:54       ` Meelis Roos
2014-01-27 15:53         ` Peter Oberparleiter
2014-01-28  6:33           ` Meelis Roos
2014-01-29 15:05             ` Peter Oberparleiter
     [not found]               ` <alpine.SOC.1.00.1401292242390.12718@math.ut.ee>
2014-01-31 15:50                 ` Peter Oberparleiter [this message]
2014-02-05 17:00                   ` Peter Oberparleiter
2014-02-05 17:36                     ` H. Peter Anvin
2014-02-06 14:58                       ` Peter Oberparleiter
2014-02-06 15:18                         ` [tip:x86/urgent] x86, hweight: Fix BUG when booting with CONFIG_GCOV_PROFILE_ALL=y tip-bot for Peter Oberparleiter
2014-02-06  6:19                     ` 3.13: BUG: unable to handle kernel paging request at 00000000b4343e88 Meelis Roos

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=52EBC65C.5020404@linux.vnet.ibm.com \
    --to=oberpar@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=borislav.petkov@amd.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mroos@linux.ee \
    /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).