Re: [PATCH] [11/18] Fix alignment bug in bootmem allocator

[Mel Gorman]

On (17/03/08 02:58), Andi Kleen didst pronounce:
> Without this fix bootmem can return unaligned addresses when the start of a
> node is not aligned to the align value. Needed for reliably allocating
> gigabyte pages.
> Signed-off-by: Andi Kleen <ak@xxxxxxx>

Seems like something that should be fixed anyway independently of your
patchset. If moved to the start of the set, it can be treated in batch with
the cleanups as well.

> 
> ---
>  mm/bootmem.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> Index: linux/mm/bootmem.c
> ===================================================================
> --- linux.orig/mm/bootmem.c
> +++ linux/mm/bootmem.c
> @@ -197,6 +197,7 @@ __alloc_bootmem_core(struct bootmem_data
>  {
>  	unsigned long offset, remaining_size, areasize, preferred;
>  	unsigned long i, start = 0, incr, eidx, end_pfn;
> +	unsigned long pfn;
>  	void *ret;
>  
>  	if (!size) {
> @@ -239,12 +240,13 @@ __alloc_bootmem_core(struct bootmem_data
>  	preferred = PFN_DOWN(ALIGN(preferred, align)) + offset;
>  	areasize = (size + PAGE_SIZE-1) / PAGE_SIZE;
>  	incr = align >> PAGE_SHIFT ? : 1;
> +	pfn = PFN_DOWN(bdata->node_boot_start);
>  

hmm, preferred is already been aligned above and it appears that "offset"
was meant to handle the situation you are dealing with here. Is the caller
passing in "goal" (to avoid DMA32 for example) and messing up how "offset"
is calculated?

>  restart_scan:
>  	for (i = preferred; i < eidx; i += incr) {
>  		unsigned long j;
>  		i = find_next_zero_bit(bdata->node_bootmem_map, eidx, i);
> -		i = ALIGN(i, incr);
> +		i = ALIGN(pfn + i, incr) - pfn;
>  		if (i >= eidx)
>  			break;
>  		if (test_bit(i, bdata->node_bootmem_map))
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/