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