From: Matt Fleming <matt@codeblueprint.co.uk>
To: lkp@lists.01.org
Subject: Re: [x86/mm/ASLR] f47233c2d34: WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:63 __ioremap_check_ram+0x445/0x4a0()
Date: Sat, 28 Feb 2015 19:20:09 +0000 [thread overview]
Message-ID: <20150228192009.GA2727@codeblueprint.co.uk> (raw)
In-Reply-To: <20150228105049.GA11038@pd.tnic>
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
On Sat, 28 Feb, at 11:50:49AM, Borislav Petkov wrote:
>
> Yeah, too many hmms means this still needed staring at to find out what
> exactly the problem is. And the problem is that allocating that struct
> setup_data statically in arch/x86/boot/compressed/aslr.c works only by
> chance, when the kernel decompressing doesn't overwrite that memory.
Doing a static allocation is fine, and the memory is even reserved from
being overwritten via memblock_x86_reserve_range_setup_data(), but it
looks like that reservation gets dropped before
get_setup_data_total_num() runs, which is what is causing ioremap() to
complain - it really is usable RAM we're trying to ioremap().
Dropping the reservation looks to happen in memblock_x86_fill(), because
you'll note that we explicitly reserve the boot services regions
immediately after memblock_x86_fill() in setup_arch().
What isn't clear right now is why the ioremap() warning isn't triggering
for a bunch of other callsites that get this wrong, i.e.
pcibios_add_device().
--
Matt Fleming, Intel Open Source Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Kees Cook <keescook@chromium.org>, Jiri Kosina <jkosina@suse.cz>,
Ingo Molnar <mingo@kernel.org>, Huang Ying <ying.huang@intel.com>,
LKML <linux-kernel@vger.kernel.org>, LKP ML <lkp@01.org>,
x86-ml <x86@kernel.org>, Dave Young <dyoung@redhat.com>,
Andy Lutomirski <luto@amacapital.net>
Subject: Re: [LKP] [x86/mm/ASLR] f47233c2d34: WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:63 __ioremap_check_ram+0x445/0x4a0()
Date: Sat, 28 Feb 2015 19:20:09 +0000 [thread overview]
Message-ID: <20150228192009.GA2727@codeblueprint.co.uk> (raw)
In-Reply-To: <20150228105049.GA11038@pd.tnic>
On Sat, 28 Feb, at 11:50:49AM, Borislav Petkov wrote:
>
> Yeah, too many hmms means this still needed staring at to find out what
> exactly the problem is. And the problem is that allocating that struct
> setup_data statically in arch/x86/boot/compressed/aslr.c works only by
> chance, when the kernel decompressing doesn't overwrite that memory.
Doing a static allocation is fine, and the memory is even reserved from
being overwritten via memblock_x86_reserve_range_setup_data(), but it
looks like that reservation gets dropped before
get_setup_data_total_num() runs, which is what is causing ioremap() to
complain - it really is usable RAM we're trying to ioremap().
Dropping the reservation looks to happen in memblock_x86_fill(), because
you'll note that we explicitly reserve the boot services regions
immediately after memblock_x86_fill() in setup_arch().
What isn't clear right now is why the ioremap() warning isn't triggering
for a bunch of other callsites that get this wrong, i.e.
pcibios_add_device().
--
Matt Fleming, Intel Open Source Technology Center
next prev parent reply other threads:[~2015-02-28 19:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 5:37 [x86/mm/ASLR] f47233c2d34: WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:63 __ioremap_check_ram+0x445/0x4a0() Huang Ying
2015-02-26 5:37 ` [LKP] " Huang Ying
2015-02-26 10:30 ` Borislav Petkov
2015-02-26 10:30 ` [LKP] " Borislav Petkov
2015-02-26 11:12 ` Ingo Molnar
2015-02-26 11:12 ` [LKP] " Ingo Molnar
2015-02-26 12:16 ` Borislav Petkov
2015-02-26 12:16 ` [LKP] " Borislav Petkov
2015-02-28 10:50 ` Borislav Petkov
2015-02-28 10:50 ` [LKP] " Borislav Petkov
2015-02-28 19:20 ` Matt Fleming [this message]
2015-02-28 19:20 ` Matt Fleming
2015-02-28 19:52 ` Borislav Petkov
2015-02-28 19:52 ` [LKP] " Borislav Petkov
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=20150228192009.GA2727@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=lkp@lists.01.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.