From patchwork Tue Mar 8 10:31:05 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 63661 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp1945310lbc; Tue, 8 Mar 2016 02:32:43 -0800 (PST) X-Received: by 10.66.102.8 with SMTP id fk8mr40668585pab.12.1457433163794; Tue, 08 Mar 2016 02:32:43 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id oz1si3932268pac.46.2016.03.08.02.32.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Mar 2016 02:32:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org; dkim=neutral (body hash did not verify) header.i=@linaro.org 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 1adEvV-0002TO-TG; Tue, 08 Mar 2016 10:31:41 +0000 Received: from mail-ig0-x22e.google.com ([2607:f8b0:4001:c05::22e]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1adEvH-0001w8-9M for linux-arm-kernel@lists.infradead.org; Tue, 08 Mar 2016 10:31:31 +0000 Received: by mail-ig0-x22e.google.com with SMTP id hb3so61536562igb.0 for ; Tue, 08 Mar 2016 02:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Ig0rBxd8ABNI8ocjXADQbOnupwQu3fxnQHAQXcBD+GQ=; b=Dl5aTj5Oh+Xtei8EMpko1UVZQJU3X5v6/S/Nxv0cfvFNHa6fNJdIuOrOTCZHOiaGk9 3XLDDPFz6/81nL/TyauD15fgiYFgxTdrlgcJd9uMQtiU3PIGrk0w41J4NrroRqLe0QKb em7SaHz2SZTQoYbuQX7CzXAkT9iMCk9tZWOPk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Ig0rBxd8ABNI8ocjXADQbOnupwQu3fxnQHAQXcBD+GQ=; b=afdUCsrlmDj5mXTLVaMRrGI7lnoDavSuT286MXOJGjtLNJCMLsVwRrDF0ai7nwenXf bHjpXwjYvQ3sqgQb0Sllo+RWFUQBj9V2eK0NlY4KseIbLdkYaRiC4wufO88KwNzQCc1i 4NiaUyomcVsBPlUlYonYf+4EjBOPauYYjnuLGy4sknTd5b+pK1ulz1c+eTncO6F1ffJA FW/x5IdTxjbo/Bzivf5sZAlRmb/ZFfL1jwMP5kvvjykMlgXN1TfENrZqZHaPaGoO/Pyr BxtMIBGv5Nht6R+XPBniCSuSD4gpw6FOwCKIqz8QsbPGE4+TU652zwPLfWFsCLxoA+ax q5qw== X-Gm-Message-State: AD7BkJLFqqaVdo48Plz7osIsUhfXcPqf3kup75vcWPgs1SjyPPQQ5W1o6/m9giqbyE9pE7AYRAq4jKbeO6iOmG0W MIME-Version: 1.0 X-Received: by 10.50.73.229 with SMTP id o5mr15709024igv.75.1457433065467; Tue, 08 Mar 2016 02:31:05 -0800 (PST) Received: by 10.36.29.6 with HTTP; Tue, 8 Mar 2016 02:31:05 -0800 (PST) In-Reply-To: References: <1456505834-8638-1-git-send-email-ard.biesheuvel@linaro.org> <1456505834-8638-2-git-send-email-ard.biesheuvel@linaro.org> <56DE25DD.4010401@gmail.com> Date: Tue, 8 Mar 2016 17:31:05 +0700 Message-ID: Subject: Re: [PATCH v2 1/2] arm64: vmemmap: use virtual projection of linear region From: Ard Biesheuvel To: David Daney , Mark Langsdorf X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160308_023127_788075_ECF8ADA7 X-CRM114-Status: GOOD ( 17.16 ) X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2607:f8b0:4001:c05:0:0:0:22e 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] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 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: , Cc: Mark Rutland , Catalin Marinas , Will Deacon , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org On 8 March 2016 at 09:15, Ard Biesheuvel wrote: > > >> On 8 mrt. 2016, at 08:07, David Daney wrote: >> >>> On 02/26/2016 08:57 AM, Ard Biesheuvel wrote: >>> Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made >>> some changes to the memory mapping code to allow physical memory to reside >>> at an offset that exceeds the size of the virtual mapping. >>> >>> However, since the size of the vmemmap area is proportional to the size of >>> the VA area, but it is populated relative to the physical space, we may >>> end up with the struct page array being mapped outside of the vmemmap >>> region. For instance, on my Seattle A0 box, I can see the following output >>> in the dmesg log. >>> >>> vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum) >>> 0xffffffbfc0000000 - 0xffffffbfd0000000 ( 256 MB actual) >>> >>> We can fix this by deciding that the vmemmap region is not a projection of >>> the physical space, but of the virtual space above PAGE_OFFSET, i.e., the >>> linear region. This way, we are guaranteed that the vmemmap region is of >>> sufficient size, and we can even reduce the size by half. >>> >>> Signed-off-by: Ard Biesheuvel >> >> I see this commit now in Linus' kernel.org tree in v4.5-rc7. >> >> FYI: I am seeing a crash that goes away when I revert this. My kernel has some other modifications (our NUMA patches) so I haven't yet fully tracked this down on an unmodified kernel, but this is what I am getting: >> > I managed to reproduce and diagnose this. The problem is that vmemmap is no longer zone aligned, which causes trouble in the zone based rounding that occurs in memory_present. The below patch fixes this by rounding down the subtracted offset. Since this implies that the region could stick off the other end, it also reverts the halving of the region size. --------8<---------- #ifndef CONFIG_KASAN #define VMALLOC_START (VA_START) @@ -52,7 +52,8 @@ #define VMALLOC_END (PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K) #define VMEMMAP_START (VMALLOC_END + SZ_64K) -#define vmemmap ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT)) +#define vmemmap ((struct page *)VMEMMAP_START - \ + ((memstart_addr >> PAGE_SHIFT) & PAGE_SECTION_MASK)) #define FIRST_USER_ADDRESS 0UL _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Tested-by: Robert Richter diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h index f50608674580..ed57c0865290 100644 --- a/arch/arm64/include/asm/pgtable.h +++ b/arch/arm64/include/asm/pgtable.h @@ -40,7 +40,7 @@ * VMALLOC_END: extends to the available space below vmmemmap, PCI I/O space, * fixed mappings and modules */ -#define VMEMMAP_SIZE ALIGN((1UL << (VA_BITS - PAGE_SHIFT - 1)) * sizeof(struct page), PUD_SIZE) +#define VMEMMAP_SIZE ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * sizeof(struct page), PUD_SIZE)