linux-kernel - Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap

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 linux-hardening linux-cve-announce 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]

Message-ID: <CAErSpo5u_KAfZL0EDVGCZ5nfvmiyv+V3+5Lw6aYoXvTouv_MeQ@mail.gmail.com>
Date:	Tue, 15 Jul 2014 14:33:41 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Fabio Coatti <fabio.coatti@...il.com>
Cc:	Stephane Eranian <eranian@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	"Yan, Zheng" <zheng.z.yan@...el.com>,
	Yinghai Lu <yinghai@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa()

[+cc Yinghai, Rafael]

On Fri, Jul 11, 2014 at 12:11 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
> On Fri, Jul 11, 2014 at 1:38 AM, Fabio Coatti <fabio.coatti@...il.com> wrote:
>> In data giovedì 10 luglio 2014 14:05:27, Bjorn Helgaas ha scritto:
>>> ...
>>> Fabio, can you pastebin your complete dmesg log?
>>
>> Sure, here you go:
>>
>> http://pastebin.com/FiL7N64b
>
> I opened this bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=80041 and attached your
> dmesg to it.  I see what the problem is, but I don't have a good idea
> yet for how to fix it.
>
> The problem is that we don't handle e820 and PNP device resource
> information correctly.  From the attached dmesg, we have this:
>
>   BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
>   system 00:00: [mem 0xfed10000-0xfed17fff] could not be reserved
>
> The 00:00 PNP device describes the correct 32K range for the Intel MCH
> (see [1] for details).  But the [mem 0xfed10000-0xfed13fff] entry from
> e820 was added to the resource map first, and it covers only the first
> 16K of the MCH range.  This caused the subsequent PNP reservation to
> fail.  Then the snb_uncore_imc_init_box() reservation caused the
> warning, because it would be a child of the e820 entry but it covers
> more space.
>
> [1] fixed a similar issue where the PNP device described only the
> first 16K of the MCH range.  This case is slightly different because
> here it's the e820 entry that is incorrect.
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cb171f7abb9a

One of the reasons for iomem_resource is so we don't hand out the same
address space to two different devices.  We *could* do that by keeping
track of the union of all devices and reserved areas that we know
about.

But the current resource code is more strict: it enforces a hierarchy.
For example, in this case, it rejects the 00:00 PNP resource because
it is larger than the e820 entry.  The problem with rejecting it is
that we might hand out [mem 0xfed14000-0xfed17fff] to another device
even though PNP told us that it's in use.

I'm about to head out for a few weeks of vacation, so I won't be able
to do anything with this.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/