On Thu, 2010-07-22 at 11:43 -0700, Yinghai Lu wrote:
> memblock_x86_to_bootmem() will reserve memblock.reserved.region in bootmem after bootmem is
> +#ifndef CONFIG_NO_BOOTMEM
> +void __init memblock_x86_to_bootmem(u64 start, u64 end)
> +{
> + int count;
> + u64 final_start, final_end;
> + struct memblock_region *r;
> +
> + /* Take out region array itself */
> + if (memblock.reserved.regions != memblock_reserved_init_regions)
> + memblock_free(__pa(memblock.reserved.regions), sizeof(struct memblock_region) * memblock.reserved.max);
So that's why you export memblock_reserved_init_regions...
I really -really- don't like it. First of all, it's really gross to
free the array then walk it. We know it won't race but still ...
especially since you re-do the above every time
memblock_x86_to_bootmem() is called. Is it called more than once ? If
yes, then it's bogus. If not, then why have start,end ?
If you really want to free it, maybe best is to stick something in
mm/memblock.c that kicks in at late init time and does the freeing ?
I'm going to keep the exporting out of my branch for now. If you really
want it, you can always add it to this specific patch, but it sucks.
Ben.
> + count = memblock.reserved.cnt;
> + pr_info("(%d early reservations) ==> bootmem [%010llx-%010llx]\n", count, start, end - 1);
> + for_each_memblock(reserved, r) {
> + pr_info(" [%010llx-%010llx] ", (u64)r->base, (u64)r->base + r->size - 1);
> + final_start = max(start, r->base);
> + final_end = min(end, r->base + r->size);
> + if (final_start >= final_end) {
> + pr_cont("\n");
> + continue;
> + }
> + pr_cont(" ==> [%010llx-%010llx]\n", final_start, final_end - 1);
> + reserve_bootmem_generic(final_start, final_end - final_start, BOOTMEM_DEFAULT);
> + }
> +
> + /* Put region array back ? */
> + if (memblock.reserved.regions != memblock_reserved_init_regions)
> + memblock_reserve(__pa(memblock.reserved.regions), sizeof(struct memblock_region) * memblock.reserved.max);
> +}
> +#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
