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]
Date:	Mon, 22 Oct 2012 13:50:38 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
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 Mon, Oct 22, 2012 at 1:26 PM, H. Peter Anvin <hpa@...ux.intel.com> wrote:
>>>> 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?

yes. or the user take out range that is not page aligned.

> Or is there a
> gap in between and memblock is still expecting to use it?

yes, current implementation is.  and init_memory_mapping map those partial pages
and holes.

>
> We should not map a partial page at the end of RAM; it is functionally
> lost.

Now we did not, we have max_low_pfn, and max_pfn to cap out end partial page.

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

ok, let's see if we can meet this extreme corner case except user
specify not page aligned "memmap="

Thanks

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