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]
Message-ID: <alpine.LFD.2.02.1206280223250.31003@xanadu.home>
Date:	Thu, 28 Jun 2012 02:25:59 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	"Kim, Jong-Sung" <neidhard.kim@....com>
cc:	'Dave Martin' <dave.martin@...aro.org>,
	'Minchan Kim' <minchan@...nel.org>,
	'Russell King' <linux@....linux.org.uk>,
	'Catalin Marinas' <catalin.marinas@....com>,
	'Chanho Min' <chanho.min@....com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-arm-kernel@...ts.infradead.org
Subject: RE: [PATCH] [RESEND] arm: limit memblock base address for
 early_pte_alloc

On Thu, 28 Jun 2012, Kim, Jong-Sung wrote:

> > From: Dave Martin [mailto:dave.martin@...aro.org]
> > Sent: Thursday, June 28, 2012 1:02 AM
> > 
> > For me, it appears that this block just contains the initial region passed
> > in ATAG_MEM or on the command line, with some reservations for
> > swapper_pg_dir, the kernel text/data, device tree and initramfs.
> > 
> > So far as I can tell, the only memory guaranteed to be mapped here is the
> > kernel image: there may be no guarantee that there is any unused space in
> > this region which could be used to allocate extra page tables.
> > The rest appears during the execution of map_lowmem().
> > 
> > Cheers
> > ---Dave
> 
> Thank you for your comment, Dave! It was not that sophisticated choice, but
> I thought that normal embedded system trying to reduce the BOM would have a
> big-enough first memblock memory region. However you're right. There can be
> exceptional systems. Then, how do you think about following manner:
[...]

This still has some possibilities for failure.

Please have a look at the two patches I've posted to fix this in a 
better way.


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