From patchwork Mon Oct 19 23:20:05 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Fainelli X-Patchwork-Id: 7440511 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 641399F302 for ; Mon, 19 Oct 2015 23:22:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6727F2064F for ; Mon, 19 Oct 2015 23:22:35 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7C0A420648 for ; Mon, 19 Oct 2015 23:22:34 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZoJjj-0005NY-C3; Mon, 19 Oct 2015 23:21:03 +0000 Received: from mail-pa0-x22c.google.com ([2607:f8b0:400e:c03::22c]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZoJjg-0005JY-Dh for linux-arm-kernel@lists.infradead.org; Mon, 19 Oct 2015 23:21:01 +0000 Received: by padhk11 with SMTP id hk11so586977pad.1 for ; Mon, 19 Oct 2015 16:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=BN8ju0XIMy0xm6VeYxA27PMhnAksUJ9uBABsbJ9BeQw=; b=RVfy6i/+B2afDMBRpXR6K/kh0VYLQoXnr54e0mEOKcPfYa4wKQhGZJGQwafpo1R7Jx 0kBCD6roH3Nta2t+eFDvc6MwbwfGpCqUlI2xhtSs9ZWmr5yhHGLv9w3fXCWDaUymb3DK PV7u21bhdCBvpU+/yZhnwUJ8P9OtOeBaE72daEr2ZscxDkFBj7Kxqj4RKIN8vQrCJBxy oE/BhttlUyYimq2MajnT2/YtWG6mHUFF5Ex/9BIZRY2t1eo8hYXLm6cEzWUdySMmddJC pt+FeNt/y5z8lY+XsMQayoiAbzfBqyYefMq9Gkf9e0ADW4hQwuy850P2HZLbpOvQC5uu CyvA== X-Received: by 10.66.194.138 with SMTP id hw10mr18236pac.71.1445296839483; Mon, 19 Oct 2015 16:20:39 -0700 (PDT) Received: from [10.12.156.244] (5520-maca-inet1-outside.broadcom.com. [216.31.211.11]) by smtp.googlemail.com with ESMTPSA id dg2sm94201pbb.9.2015.10.19.16.20.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 16:20:38 -0700 (PDT) Message-ID: <56257AA5.1030800@gmail.com> Date: Mon, 19 Oct 2015 16:20:05 -0700 From: Florian Fainelli User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk, labbott@fedoraproject.org, Gregory Fong Subject: vmalloc_reserve with no highmem X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20151019_162100_505871_5EE93833 X-CRM114-Status: GOOD ( 15.26 ) X-Spam-Score: -2.7 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Russell, Laura, Setting vmalloc= on the kernel command-line to define the amount of vmalloc_reserve is not quite working when you have no highmem, as is the case of one my boards which has 512MB or 256M populated on a first bank at PA 0x0. What happens in that case is that, despite setting vmalloc_reserve, therefore bumping up vmalloc_min to a higher address than high_memory, which is assigned __va(arm_lowmem_limit), we end-up with VMALLOC_START at high_memory + VMALLOC_OFFSET, which yields the amount of physical memory (start at PA 0x0 in my case) - VMALLOC_OFFSET. The maths look like this for this particular board (512MB) high_memory = 0x20000000 + PAGE_OFFSET = 0x20000000 + 0xC0000000 = 0xE0000000 vmalloc_min = 0xFF00000 - (248 * 1024 * 1024) = 0xEF800000 so we end-up with VMALLOC_START = high_memory + VMALLOC_OFFSET = 0xE0000000 + 8 * 1024* 1024 = 0xE0800000 in sanity_check_meminfo(), high_memory is unconditionally assigned with arm_lowmem_limit's VA. The following quick and dirty patch seems to do it for me, but I am not confident this is remotely the correct approach here: things, is that intended? Thanks! diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index 14428d2..e196ea4 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -1196,7 +1211,14 @@ void __init sanity_check_meminfo(void) } #endif meminfo.nr_banks = j; - high_memory = __va(arm_lowmem_limit - 1) + 1; + + if (vmalloc_limit > arm_lowmem_limit) + high_memory = vmalloc_min - VMALLOC_OFFSET; + else + high_memory = __va(arm_lowmem_limit - 1) + 1; + + pr_info("%s: high_memory: 0x%p, arm_lowmem_limit: 0x%llx\n", + __func__, high_memory, arm_lowmem_limit); BTW, even when there is highmem available, setting vmalloc= on the command-line is off by VMALLOC_OFFSET, the way early_vmalloc() computes