From patchwork Tue Nov 21 03:44:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chen Feng X-Patchwork-Id: 119335 Delivered-To: patch@linaro.org Received: by 10.140.22.164 with SMTP id 33csp4729313qgn; Mon, 20 Nov 2017 19:44:30 -0800 (PST) X-Google-Smtp-Source: AGs4zMYF/drqzfHR7ofvF9n7mgemd36+ylPY7ZktkNwh+Cu2FB56fdLLp8Gt152XWtyazpwlmK8Q X-Received: by 10.84.244.193 with SMTP id f1mr16412137plt.32.1511235870796; Mon, 20 Nov 2017 19:44:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511235870; cv=none; d=google.com; s=arc-20160816; b=QXAZlnAftd4jttpIjNDGMekcSj8cHEdpzW7aM49EXzRK8k66pcDDJNrmy9A85i8Szy FmzMKBdAACXE6S4LVJzBkHxDUX0KIZYLlFpgY4EUqX/EWp4pKlPV7lqkDTpx/Uf8Wv4X +rD1sROEARRY6tgTjmJAu3aSA4/SSqLpruqWMVW3hJ4r3uYxtY8w2LJCJMjWiLou+5K9 jd1v3dIL9M+C2JCQHEQlH3OLnjKKwBmisfULHleEIgMfsoSzEyxgI9s0mN0JAKZhjAsl BsvMzZOT/ELqEi6Tq4L4fYpGOSXOtOnDsqB+NIA7+NKGJCBAXpDZeh0TOpDdBPuoVvN2 w7zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=6ITwrxGGVclWzgKRRpoQPv4E5ooE4RTNCrUimC6jLpI=; b=qlcAlUsz6GFUgERey7Rwom8N5L4TAleoTSlL/gG2w+D1y9N8yi5sb9J7cQe9J8lXaD sbfFBwYlhY3lUqZFC9eP0HqweKOJooHHCB51aVDsZvXx9tf7OHmqta+fny7n30CotfrE jBXdTIgn8yjkZQhp1WjNzlW9CwpPf7Z/AioVNgC1aodITyttXn9xP+exgWkEj9ukYf/1 GakPOLiQJxGq/FyajhJCKOAjOIFGKqGbAuNfoC3BbyC4G+IISvRxu3wqxn7CObRLllNQ VMc1r1r1Ko/c+Jtqchj/75MyRpiL4KDQe/4f/gFEXt0XwPZ1e6j1xwzIVJV7RGeZMwjU QvoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a61si3929265pla.234.2017.11.20.19.44.30; Mon, 20 Nov 2017 19:44:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752539AbdKUDo2 (ORCPT + 20 others); Mon, 20 Nov 2017 22:44:28 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:11013 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752265AbdKUDo1 (ORCPT ); Mon, 20 Nov 2017 22:44:27 -0500 Received: from 172.30.72.60 (EHLO DGGEMS411-HUB.china.huawei.com) ([172.30.72.60]) by dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id DLI98550; Tue, 21 Nov 2017 11:44:20 +0800 (CST) Received: from vm163-62.huawei.com (10.184.163.62) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.361.1; Tue, 21 Nov 2017 11:44:13 +0800 From: Chen Feng To: , , , , , CC: , , , , , , Subject: [PATCH] arm64: kaslr: Fix kaslr end boundary of virt addr Date: Tue, 21 Nov 2017 11:44:13 +0800 Message-ID: <1511235853-8407-1-git-send-email-puck.chen@hisilicon.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 X-Originating-IP: [10.184.163.62] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5A13A114.0094, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5da194cbcaf321afd538e0dbcd64cd6b Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org With kaslr and kasan enable both, I got the follow issue. [ 16.130523s]kasan: reg->base = 100000000, phys_end =1c0000000,start = ffffffff40000000, end = ffffffc000000000 [ 16.142517s]___alloc_bootmem_nopanic:257 [ 16.148284s]__alloc_memory_core_early:63, addr = 197fc7fc0 [ 16.155670s]__alloc_memory_core_early:65, virt = ffffffffd7fc7fc0 [ 16.163635s]__alloc_memory_core_early:67, toshow = ffffff8ffaff8ff8 [ 16.171783s]__alloc_memory_core_early:69, show_phy = ffffffe2649f8ff8 [ 16.180145s]Unable to handle kernel paging request at virtual address ffffff8ffaff8ff8 [ 16.189971s]pgd = ffffffad9c507000 [ 16.195220s][ffffff8ffaff8ff8] *pgd=0000000197fc8003, *pud=0000000197fc8003 *reg->base = 100000000, phys_end =1c0000000,start = ffffffff40000000, end = ffffffc000000000* memstart_addr 0 ARM64_MEMSTART_ALIGN 0x40000000 memstart_offset_seed 0xffc7 PHYS_OFFSET = 0 - memstart_addr = 0 - 3E40000000 = FFFFFFC1C0000000 reg->base = 0x100000000 -> 0xffffffff40000000 phys_end = 0x1c0000000 -> 0xffffffc000000000 This is confused, end less than start. And In memblock it use "start_addr + size" as the end addr. So in function kasan_init, if the start >= end, it will not map the hole block address. But the memory in this block is valid. And it can be allocated as well. So donot use the last memory region. Changing "range = range / ARM64_MEMSTART_ALIGN + 1" to range = range / ARM64_MEMSTART_ALIGN; Signed-off-by: Chen Feng Signed-off-by: Chen Xiang --- arch/arm64/mm/init.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) -- 1.9.1 diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 716d122..60112c0 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -267,11 +267,8 @@ void __init arm64_memblock_init(void) * margin, the size of the region that the available physical * memory spans, randomize the linear region as well. */ - if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) { - range = range / ARM64_MEMSTART_ALIGN + 1; - memstart_addr -= ARM64_MEMSTART_ALIGN * - ((range * memstart_offset_seed) >> 16); - } + if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) + memstart_addr -= (range * memstart_offset_seed) >> 16; } /*