Messages in this thread | | | Date | Mon, 18 Jun 2012 16:46:40 -0700 | Subject | Re: [PATCH] memblock: Make sure reserved.regions is freed really | From | Yinghai Lu <> |
| |
On Mon, Jun 18, 2012 at 4:09 PM, Tejun Heo <tj@kernel.org> wrote: > Hey, Yinghai. > > On Mon, Jun 18, 2012 at 03:58:52PM -0700, Yinghai Lu wrote: >> > Hmmm... nice catch but I think it's a bit complex and ugly. In this >> > case, we *know* that the region isn't gonna be split. Maybe a better >> > option is to add something like the following? >> >> how do you know __pa(memblock.reserved.regions) would not be merged >> with other entries >> in reserved.regions? >> >> > >> > void memblock_remove_region_by_ptr(struct memblock_type *type, >> > struct memblock_region *r) >> > { >> > WARN_ON(/* make sure @r is inside @type->regions */); >> > memblock_remove_region(type, r - type->regions); >> > } >> >> you want to change > > Heh, you're right. My suggestion was completely bonkers. Sorry about > that. Hmm.... how about separating out removal pre-expansion and > doing it before calling into free? ie. something like > > static int memblock_prepare_for_isolation(struct memblock_type *type) > { > /* we'll create at most two more regions */ > while (type->cnt + 2 > type->max) > if (memblock_double_array(type) < 0) > return -ENOMEM; > return 0; > } > > int __init_memblock memblock_free_reserved_regions(void) > { > int ret; > > if (memblock.reserved.regions == memblock_reserved_init_regions) > return 0; > > ret = memblock_prepare_for_isolation(&memblock.reserved); > if (ret) > return ret; > > ret = memblock_free(__pa(memblock.reserved.regions), > sizeof(struct memblock_region) * memblock.reserved.max); > WARN_ON(ret || memblock.reserved.regions has changed); > return ret; > }
yes. that looks good. but that WARN_ON looks wrong, could just drop that line.
Please send complete version to Andrew or Linus.
Thanks
Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |