linux-kernel - Re: Early boot panic on machine with lots of memory

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:	Fri, 22 Jun 2012 12:23:24 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Gavin Shan <shangw@...ux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>, hpa@...ux.intel.com,
	linux-mm <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Early boot panic on machine with lots of memory

On Fri, Jun 22, 2012 at 11:51 AM, Tejun Heo <tj@...nel.org> wrote:
> Hello, Yinghai.
>>
>> Also I add another patch to double check if there is any reference
>> with reserved.region.
>> so far there is no reference found.
>
> Thanks for checking it.  I was worried because of the re-reservation
> of reserved.regions after giving memory to the page allocator -
> ie. memblock_reserve_reserved_regions() call.  If memblock is done at
> that point, there's no reason to have that call at all.  It could be
> that that's just dead code.  If so, why aren't we freeing
> memory.regions?

During converting bootmem to use early_res stage, I still kept the
numa handling.
like one node by one node. So need to put the reserved.regions back.
Later found we could do that for all node at the same time.

For memory.regions, a little different, at that time I want to kill
e820 all like e820_all_mapped_ram.

Yes, we should get back region that is allocated for doubled memory.regions.
but did not trigger that doubling yet.

Also for x86, all memblock in __initdata, and will be freed later.

> Also, shouldn't we be clearing
> memblock.cnt/max/total_size/regions so that we know for sure that it's
> never used again?  What am I missing?

64bit mem_init(), after absent_page_in_range(), will not need memblock anymore.
  --- absent_page_in_range will refer for_each_mem_pfn_range.

so after that could clear that for memory.regions too.

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/