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

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:	Tue, 18 Mar 2008 16:18:21 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, pj@....com, linux-mm@...ck.org,
	nickpiggin@...oo.com.au
Subject: Re: [PATCH] [11/18] Fix alignment bug in bootmem allocator

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@...e.de>

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/