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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1378254257.10300.921.camel@misato.fc.hp.com>
Date:	Tue, 03 Sep 2013 18:24:17 -0600
From:	Toshi Kani <toshi.kani@...com>
To:	Tang Chen <tangchen@...fujitsu.com>
Cc:	rjw@...k.pl, lenb@...nel.org, tglx@...utronix.de, mingo@...e.hu,
	hpa@...or.com, akpm@...ux-foundation.org, tj@...nel.org,
	trenn@...e.de, yinghai@...nel.org, jiang.liu@...wei.com,
	wency@...fujitsu.com, laijs@...fujitsu.com,
	isimatu.yasuaki@...fujitsu.com, izumi.taku@...fujitsu.com,
	mgorman@...e.de, minchan@...nel.org, mina86@...a86.com,
	gong.chen@...ux.intel.com, vasilis.liaskovitis@...fitbricks.com,
	lwoodman@...hat.com, riel@...hat.com, jweiner@...hat.com,
	prarit@...hat.com, zhangyanfei@...fujitsu.com, x86@...nel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 06/11] memblock: Improve memblock to support allocation
 from lower address.

On Tue, 2013-08-27 at 17:37 +0800, Tang Chen wrote:
> This patch modifies the memblock_find_in_range_node() to support two
> different allocation orders. After this patch, memblock will check
> memblock.current_order, and decide in which order to allocate memory.
> 
> Signed-off-by: Tang Chen <tangchen@...fujitsu.com>
> Reviewed-by: Zhang Yanfei <zhangyanfei@...fujitsu.com>
> ---
>  mm/memblock.c |   90 +++++++++++++++++++++++++++++++++++++++++++++++---------
>  1 files changed, 75 insertions(+), 15 deletions(-)
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 8f1e2d4..961d4a5 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -85,6 +85,77 @@ static long __init_memblock memblock_overlaps_region(struct memblock_type *type,
>  }
>  
>  /**
> + * __memblock_find_range - find free area utility
> + * @start: start of candidate range, can be %MEMBLOCK_ALLOC_ACCESSIBLE
> + * @end: end of candidate range, can be %MEMBLOCK_ALLOC_{ANYWHERE|ACCESSIBLE}
> + * @size: size of free area to find
> + * @align: alignment of free area to find
> + * @nid: nid of the free area to find, %MAX_NUMNODES for any node
> + *
> + * Utility called from memblock_find_in_range_node(), find free area from
> + * lower address to higher address.
> + *
> + * RETURNS:
> + * Found address on success, %0 on failure.
> + */
> +phys_addr_t __init_memblock
> +__memblock_find_range(phys_addr_t start, phys_addr_t end,
> +		      phys_addr_t size, phys_addr_t align, int nid)

This func should be static as it must be an internal func.

> +{
> +	phys_addr_t this_start, this_end, cand;
> +	u64 i;
> +
> +	for_each_free_mem_range(i, nid, &this_start, &this_end, NULL) {
> +		this_start = clamp(this_start, start, end);
> +		this_end = clamp(this_end, start, end);
> +
> +		cand = round_up(this_start, align);
> +		if (cand < this_end && this_end - cand >= size)
> +			return cand;
> +	}
> +	return 0;
> +}
> +
> +/**
> + * __memblock_find_range_rev - find free area utility, in reverse order
> + * @start: start of candidate range, can be %MEMBLOCK_ALLOC_ACCESSIBLE
> + * @end: end of candidate range, can be %MEMBLOCK_ALLOC_{ANYWHERE|ACCESSIBLE}
> + * @size: size of free area to find
> + * @align: alignment of free area to find
> + * @nid: nid of the free area to find, %MAX_NUMNODES for any node
> + *
> + * Utility called from memblock_find_in_range_node(), find free area from
> + * higher address to lower address.
> + *
> + * RETURNS:
> + * Found address on success, %0 on failure.
> + */
> +phys_addr_t __init_memblock
> +__memblock_find_range_rev(phys_addr_t start, phys_addr_t end,
> +			  phys_addr_t size, phys_addr_t align, int nid)

Ditto.

> +{
> +	phys_addr_t this_start, this_end, cand;
> +	u64 i;
> +
> +	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
> +		this_start = clamp(this_start, start, end);
> +		this_end = clamp(this_end, start, end);
> +
> +		/*
> +		 * Just in case that (this_end - size) underflows and cause
> +		 * (cand >= this_start) to be true incorrectly.
> +		 */
> +		if (this_end < size)
> +			break;
> +
> +		cand = round_down(this_end - size, align);
> +		if (cand >= this_start)
> +			return cand;
> +	}
> +	return 0;
> +}
> +
> +/**
>   * memblock_find_in_range_node - find free area in given range and node
>   * @start: start of candidate range, can be %MEMBLOCK_ALLOC_ACCESSIBLE
>   * @end: end of candidate range, can be %MEMBLOCK_ALLOC_{ANYWHERE|ACCESSIBLE}
> @@ -110,9 +181,6 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
>  					phys_addr_t end, phys_addr_t size,
>  					phys_addr_t align, int nid)
>  {
> -	phys_addr_t this_start, this_end, cand;
> -	u64 i;
> -
>  	/* pump up @start and @end */
>  	if (start == MEMBLOCK_ALLOC_ACCESSIBLE)
>  		start = memblock.current_limit_low;
> @@ -123,18 +191,10 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
>  	start = max_t(phys_addr_t, start, PAGE_SIZE);
>  	end = max(start, end);
>  
> -	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
> -		this_start = clamp(this_start, start, end);
> -		this_end = clamp(this_end, start, end);
> -
> -		if (this_end < size)
> -			continue;
> -
> -		cand = round_down(this_end - size, align);
> -		if (cand >= this_start)
> -			return cand;
> -	}
> -	return 0;
> +	if (memblock.current_order == MEMBLOCK_ORDER_DEFAULT)

This needs to use MEMBLOCK_ORDER_HIGH_TO_LOW since the code should be
independent from the value of MEMBLOCK_ORDER_DEFAULT.

Thanks,
-Toshi


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ