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:29:19 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Yinghai Lu <yinghai@...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

Hello, Yinghai.

On Fri, Jun 22, 2012 at 12:23:24PM -0700, Yinghai Lu wrote:
> > 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.

Thanks for the explanation.

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

I wish we had a single call - say, memblock_die(), or whatever - so
that there's a clear indication that memblock usage is done, but yeah
maybe another day.  Will review the patch itself.  BTW, can't you post
patches inline anymore?  Attaching is better than corrupt but is still
a bit annoying for review.

Thanks.

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