linux-kernel - [PATCH 1/5] mm/memblock: truncate memblock if necessary

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-next>] [day] [month] [year] [list]

Message-Id: <1345818820-12102-1-git-send-email-liwanp@linux.vnet.ibm.com>
Date:	Fri, 24 Aug 2012 22:33:36 +0800
From:	Wanpeng Li <liwanp@...ux.vnet.ibm.com>
To:	linux-mm@...ck.org
Cc:	linux-kernel@...r.kernel.org, Michal Hocko <mhocko@...e.cz>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Minchan Kim <minchan@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Gavin Shan <shangw@...ux.vnet.ibm.com>,
	Wanpeng Li <liwanp@...ux.vnet.ibm.com>
Subject: [PATCH 1/5] mm/memblock: truncate memblock if necessary

From: Gavin Shan <shangw@...ux.vnet.ibm.com>

While enforcing memory limit on current memblock layout, it is
possible that we don't have to change the current memblock layout.
For example, the enforced limited size is bigger than the maximal
address of memory regions. Also, we don't have to change the memory
layout while the enforced limited size is more than the accumulative
size of all memory regions.

The patch checks them and won't change current memblock layout for
those cases, thus to reduce some overhead.

Signed-off-by: Gavin Shan <shangw@...ux.vnet.ibm.com>
Signed-off-by: Wanpeng Li <liwanp@...ux.vnet.ibm.com>
---
 mm/memblock.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 4d9393c..c1fbb12 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -844,14 +844,14 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
 	unsigned long i;
 	phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX;
 
-	if (!limit)
+	if (!limit || limit >= memblock_end_of_DRAM())
 		return;
 
 	/* find out max address */
 	for (i = 0; i < memblock.memory.cnt; i++) {
 		struct memblock_region *r = &memblock.memory.regions[i];
 
-		if (limit <= r->size) {
+		if (limit < r->size) {
 			max_addr = r->base + limit;
 			break;
 		}
@@ -859,8 +859,12 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
 	}
 
 	/* truncate both memory and reserved regions */
-	__memblock_remove(&memblock.memory, max_addr, (phys_addr_t)ULLONG_MAX);
-	__memblock_remove(&memblock.reserved, max_addr, (phys_addr_t)ULLONG_MAX);
+	if (max_addr < (phys_addr_t)ULLONG_MAX) {
+		__memblock_remove(&memblock.memory, max_addr,
+						(phys_addr_t)ULLONG_MAX);
+		__memblock_remove(&memblock.reserved, max_addr,
+						(phys_addr_t)ULLONG_MAX);
+	}
 }
 
 static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
-- 
1.7.5.4

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