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:	Thu, 6 Feb 2014 18:41:53 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Santosh Shilimkar <santosh.shilimkar@...com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Yinghai Lu <yinghai@...nel.org>,
	"Strashko, Grygorii" <grygorii.strashko@...com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] ARM: mm: Fix the memblock allocation for LPAE machines

On Wed, Feb 05, 2014 at 07:50:55PM -0500, Santosh Shilimkar wrote:
> On Wednesday 05 February 2014 06:48 PM, Russell King - ARM Linux wrote:
> > On Wed, Feb 05, 2014 at 06:39:44PM -0500, Santosh Shilimkar wrote:
> >> Russell,
> >>
> >> On Saturday 01 February 2014 03:14 PM, Santosh Shilimkar wrote:
> >>> Commit ad6492b8 added much needed memblock_virt_alloc_low() and further
> >>> commit 07bacb3 {memblock, bootmem: restore goal for alloc_low} fixed the
> >>> issue with low memory limit thansk to Yinghai. But even after all these fixes,
> >>> there is still one case where the limit check done with ARCH_LOW_ADDRESS_LIMIT
> >>> for low memory fails. Russell pointed out the issue with 32 bit LPAE machines
> >>> in below thread.
> >>> 	https://lkml.org/lkml/2014/1/28/364
> >>>
> >>> Since on some LPAE machines where memory start address is beyond 4GB,
> >>> the low memory marker in memblock will be set to default
> >>> ARCH_LOW_ADDRESS_LIMIT which is wrong. We can fix this by letting
> >>> architectures set the ARCH_LOW_ADDRESS_LIMIT using another export
> >>> similar to memblock_set_current_limit() but am not sure whether
> >>> its worth the trouble. Tell me if you think otherwise.
> >>>
> >>> Rather am just trying to fix that one broken case using memblock_virt_alloc()
> >>> in setup code since the memblock.current_limit is updated appropriately
> >>> makes it work on all ARM 32 bit machines.
> >>>
> >>> Cc: Yinghai Lu <yinghai@...nel.org>
> >>> Cc: Russell King <linux@....linux.org.uk>
> >>> Cc: Strashko, Grygorii <grygorii.strashko@...com>
> >>> Cc: Andrew Morton <akpm@...ux-foundation.org>
> >>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@...com>
> >>> ---
> >> Whats you say here ? We should get the fix for the
> >> issue. If you are ok, I can drop the patch in patch system.
> > 
> > Is this still an issue, or has Tejun fixed it by some other means?  I've not
> > noticed anything being broken at the moment.
> > 
> > Can you confirm whether we still have an issue without this patch please?
> > 
> Fixes for all cases exist except 'LPAE + memory start beyond 4 GB'.
> This case is still broken and  hence I posted the $subject patch.

Okay.  Patch system please then.  Thanks.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
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