From patchwork Fri Aug 10 15:14:05 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jonathan Austin X-Patchwork-Id: 176511 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from merlin.infradead.org (unknown [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 510CF2C008E for ; Sat, 11 Aug 2012 01:17:22 +1000 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1Szquj-0004pH-La; Fri, 10 Aug 2012 15:14:13 +0000 Received: from service87.mimecast.com ([91.220.42.44]) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1Szque-0004oj-8v for linux-arm-kernel@lists.infradead.org; Fri, 10 Aug 2012 15:14:11 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Fri, 10 Aug 2012 16:14:05 +0100 Received: from [10.1.68.61] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Aug 2012 16:15:43 +0100 Message-ID: <5025253D.3010007@arm.com> Date: Fri, 10 Aug 2012 16:14:05 +0100 From: Jonathan Austin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: =?UTF-8?B?5rmb5oyv5rOi?= Subject: Re: Why the region area don't decrease 1 in function sanity_check_meminfo? References: In-Reply-To: X-OriginalArrivalTime: 10 Aug 2012 15:15:43.0951 (UTC) FILETIME=[02D595F0:01CD770B] X-MC-Unique: 112081016140501901 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [91.220.42.44 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Catalin Marinas , Will Deacon , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org On 24/07/12 11:54, 湛振波 wrote: > I don't known why the memory region have not decrease 1, i think it > should be decreased(like this , (__va(bank->start + bank->size > -1))because in sparse memory system, this address bank->start + > bank->size is belong to another bank, so this method is not correctly. I think you're right - we should have the '- 1' in there, although I don't think there currently exist any situations where this will cause us grief. Here's a patch for correctness anyway... > Please indicate whether my understanding is correct. As far as I can see in all existing situations, the worst effect of this will be truncating by a single byte a bank that doesn't actually need truncating. As you said in your following email, we would get trouble with this if using SPARSEMEM in a situation where the physical to virtual address conversion is not monotonic increasing. Jonny ---8<--- From: Jonathan Austin Date: Thu, 9 Aug 2012 15:59:16 +0100 Subject: [PATCH] arm: mm: Fix vmalloc overlap check for !HIGHMEM With !HIGHMEM, sanity_check_meminfo checks for banks that completely or partially overlap the vmalloc region. The check for partial overlap checks __va(bank->start + bank->size) > vmalloc_min, but the last address of the bank is (bank->start + bank->size -1). This doesn't cause serious issues for existing platforms, except to truncate by a single byte a bank that doesn't actually need truncating if it happens to finish at vmalloc_min -1. However, theoretically, if using using SPARSEMEM in a situation where the physical to virtual address conversion is not monotonic increasing, the incorrect test could result in a bank not being truncated when it should be. Reported-by: 湛振波 (Steve) Signed-off-by: Jonathan Austin --- arch/arm/mm/mmu.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index 4c2d045..29f7084 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -961,8 +961,8 @@ void __init sanity_check_meminfo(void) * Check whether this memory bank would partially overlap * the vmalloc area. */ - if (__va(bank->start + bank->size) > vmalloc_min || - __va(bank->start + bank->size) < __va(bank->start)) { + if (__va(bank->start + bank->size - 1) > vmalloc_min || + __va(bank->start + bank->size - 1) < __va(bank->start)) { unsigned long newsize = vmalloc_min - __va(bank->start); printk(KERN_NOTICE "Truncating RAM at %.8llx-%.8llx " "to -%.8llx (vmalloc region overlap).\n",