linux-kernel - Re: [PATCH] Skip memory holes in FLATMEM when reading /proc/pagetypeinfo (resend)

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, 21 Aug 2008 17:56:48 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Mel Gorman <mel@....ul.ie>, hsweeten@...ionengravers.com,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Skip memory holes in FLATMEM when reading /proc/pagetypeinfo (resend)

On Thu, Aug 21, 2008 at 09:34:00AM -0700, Andrew Morton wrote:
> On Thu, 21 Aug 2008 14:28:05 +0100 Mel Gorman <mel@....ul.ie> wrote:
> > This patch lets architectures say when FLATMEM can have holes in the
> > memmap. Rather than an expensive check for valid memory, /proc/pagetypeinfo
> > will confirm that the page linkages are still valid by checking page->zone
> > is still the expected zone. The lookup of page_zone is safe as there is a
> > limited range of memory that is accessed when calling page_zone.  Even if
> > page_zone happens to return the correct zone, the impact is that the counters
> > in /proc/pagetypeinfo are slightly off but fragmentation monitoring is
> > unlikely to be relevant on an embedded system.
> 
> Sounds like this might fix an oops.  Does it?
> 
> The patch applies to 2.6.25 and to 2.6.26.  Should it be backported?

The only concern there is with this patch is that we're still walking
over the memory, which could contain anything.  We could be unlucky
and end up with page_zone(page) == zone.

It'll do as a stop gap, but I think the real solution is to switch over
to using sparsemem, and get rid of ARMs private version (which even
pre-dates discontigmem.)  That first assumes that we have sparsemem
working on ARM - however folk seem to prefer discontigmem over
sparsemem so I don't know what state sparsemem on ARM is in. :(
--
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/