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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 22 Oct 2012 13:26:23 -0700
From:	"H. Peter Anvin" <hpa@...ux.intel.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Jacob Shin <jacob.shin@....com>, Tom Rini <trini@...com>,
	hpa@...or.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stable@...nel.org" <stable@...nel.org>
Subject: Re: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on
 boot

On 10/22/2012 12:46 PM, Yinghai Lu wrote:
> On Mon, Oct 22, 2012 at 11:38 AM, Jacob Shin <jacob.shin@....com> wrote:
>>
>> Does EFI do this on above 4G memory? All the EFI BIOSes we have in house looked
>> to be only touching under 4G.
> 
> I have no idea about it.
> 

I don't think we can rely on what is happening right now anyway.

>>> 2. partial page:
>>>    E820 or user could pass memmap that  is not page aligned.
>>>    old cold will guarded by max_low_pfn and max_pfn. so the end partial
>>>    page will be trimmed down, and memblock can one use it.
>>>    middle partial page will still get covered by directly mapping, and
>>> memblock still can use them.
>>>    Now we will not map middle partial page and memblock still try to use it
>>> we could get panic when accessing those pages.
>>>
>>> So I would suggest to just revert that temporary patch at this time,
>>> and later come out one complete patch for stable kernels.
>>
>> Hm okay, I was hoping not, but if it has to be ..
> 
> It's hpa's call.

So the issue is that two E820 RAM ranges (or ACPI, or kernel-reserved)
are immediately adjacent on a non-page-aligned address?  Or is there a
gap in between and memblock is still expecting to use it?

We should not map a partial page at the end of RAM; it is functionally
lost.  Two immediately adjacent pages could be coalesced, but not a
partial page that abuts I/O space (and yes, such abortions can happen in
the real world.)

However, the issue obviously is that what we can realistically put in
3.7 or stable is limited at this point.

	-hpa



--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ