From patchwork Fri Mar 11 10:44:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Catalin Marinas X-Patchwork-Id: 63753 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp956814lbc; Fri, 11 Mar 2016 02:46:08 -0800 (PST) X-Received: by 10.66.54.78 with SMTP id h14mr2086957pap.95.1457693168045; Fri, 11 Mar 2016 02:46:08 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id uf7si3419652pac.150.2016.03.11.02.46.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Mar 2016 02:46:08 -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 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 1aeKZE-0000FA-M9; Fri, 11 Mar 2016 10:45:12 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aeKZ9-00086g-RD for linux-arm-kernel@lists.infradead.org; Fri, 11 Mar 2016 10:45:09 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 107AB49; Fri, 11 Mar 2016 02:43:46 -0800 (PST) Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com [10.1.203.148]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5C4133F211; Fri, 11 Mar 2016 02:44:44 -0800 (PST) Date: Fri, 11 Mar 2016 10:44:41 +0000 From: Catalin Marinas To: Ard Biesheuvel Subject: Re: [PATCH] arm64: kasan: Use actual memory node when populating the kernel image shadow Message-ID: <20160311104441.GA27733@e104818-lin.cambridge.arm.com> References: <1457636243-17382-1-git-send-email-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160311_024507_987810_CBE8DDFE X-CRM114-Status: GOOD ( 15.39 ) X-Spam-Score: -6.9 (------) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-6.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.101.70 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 , Andrey Ryabinin , James Morse , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org On Fri, Mar 11, 2016 at 09:31:02AM +0700, Ard Biesheuvel wrote: > On 11 March 2016 at 01:57, Catalin Marinas wrote: > > With the 16KB or 64KB page configurations, the generic > > vmemmap_populate() implementation warns on potential offnode > > page_structs via vmemmap_verify() because the arm64 kasan_init() passes > > NUMA_NO_NODE instead of the actual node for the kernel image memory. > > > > Fixes: f9040773b7bb ("arm64: move kernel image to base of vmalloc area") > > Signed-off-by: Catalin Marinas > > Reported-by: James Morse > > I still think using vmemmap_populate() is somewhat of a hack here, and > the fact that we have different versions for 4k pages and !4k pages, > while perhaps justified for the actual real purpose of allocating > struct page arrays, makes this code more fragile than it needs to be. I agree, kasan is hijacking API meant for something else. > How difficult would it be to simply have a kasan specific > vmalloc_shadow() function that performs a > memblock_alloc/create_mapping, and does the right thing wrt aligning > the edges, rather than putting knowledge about how vmemmap_populate > happens to align its allocations into the kasan code? With a long flight from Bangkok, who knows, I may see some patches on Monday ;) Anyway, I think we also need to change the 4K pages vmemmap_populate to do a vmemmap_verify in all cases, something like below (untested): -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index d2d8b8c2e17f..c0f61235a6ec 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -642,8 +642,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node) return -ENOMEM; set_pmd(pmd, __pmd(__pa(p) | PROT_SECT_NORMAL)); - } else - vmemmap_verify((pte_t *)pmd, node, addr, next); + } + vmemmap_verify((pte_t *)pmd, node, addr, next); } while (addr = next, addr != end); return 0;