linux-kernel - Re: Re: [PATCH]Fix usemap for DISCONTIG/FLATMEM with not-aligned zone initilaization.

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:	Sat, 19 Apr 2008 02:25:56 +0900 (JST)
From:	kamezawa.hiroyu@...fujitsu.com
To:	Mel Gorman <mel@....ul.ie>
Cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Shi Weihua <shiwh@...fujitsu.com>, akpm@...ux-foundation.org,
	balbir@...ux.vnet.ibm.com, xemul@...nvz.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, hugh@...itas.com
Subject: Re: Re: [PATCH]Fix usemap for DISCONTIG/FLATMEM with not-aligned zone initilaization.

Thank you for looking into.

>> -		if ((pfn & (pageblock_nr_pages-1)))
>> -			set_pageblock_migratetype(page, MIGRATE_MOVABLE);
>> +		set_pageblock_migratetype(page, MIGRATE_MOVABLE);
>>  
>
>The point of the if there was so that set_pageblock_migratetype() would
>only be called once per pageblock. The impact with an unaligned zone is
>that the first block is not set and will be used for UNMOVABLE pages
>initially. However, this is not a major impact and there is no need to
>call set_pageblock_migratetype for every page.
>
But if ((pfn & (pageblock_nr_pages -1))) is not correct.
for calling set_pageblock_migrationtype() once in a pageblock,
!((pfn & (pageblock_nr_pages -1))) is correct.


>
>This is a pretty large change for what seems to be a fairly basic problem -
I think so ;(

>alignment issues during boot where I'm guessing we are writing past the end
>of the bitmap. Even if the virtual memmap is covering non-existant pages,
>the PFNs there for bitmaps and the like should still not be getting used
>and the map size is already rounded up to the pageblock size. It's also
>expanding the size of zone which seems overkill.
>
>I think I have a possible alternative fix below.
>
ok.

>What about something like the following? Instead of expanding the size of
>structures, it sanity checks input parameters. It touches a number of places
>because of an API change but it is otherwise straight-forward.
>
>Unfortunately, I do not have an IA-64 machine that can reproduce the problem
>to see if this still fixes it or not so a test as well as a review would be
>appreciated. What should happen is the machine boots but prints a warning
>about the unexpected PFN ranges. It boot-tested fine on a number of other
>machines (x86-32 x86-64 and ppc64).
>
ok, I'll test today if I have a chance. At least, I think I can test this
until Monday. but I have one concern (below)


>+	/*
>+	 * Sanity check the values passed in. It is possible an architecture
>+	 * calling this function directly will use values outside of the memory
>+	 * they registered
>+	 */
>+	if (start_pfn < zone->zone_start_pfn) {
>+		WARN_ON_ONCE(1);
>+		start_pfn = zone->zone_start_pfn;
>+	}
>+
>+	if (size > zone->spanned_pages) {
>+		WARN_ON_ONCE(1);
>+		size = zone->spanned_pages;
>+	}
> 
My concern here is, memmap out-of-zone is not initialized and not
marked as PG_reserved...sholdn't we initialize existing memmap even
if they are out-ot-zone ? I think all existing mem_map for memory hole
should be initialized properly.

Thanks,
-Kame

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