From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B956C433EF for ; Tue, 28 Sep 2021 07:49:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 290E16113E for ; Tue, 28 Sep 2021 07:49:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 290E16113E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 72579900003; Tue, 28 Sep 2021 03:49:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D508900002; Tue, 28 Sep 2021 03:49:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 575FE900003; Tue, 28 Sep 2021 03:49:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id 47749900002 for ; Tue, 28 Sep 2021 03:49:14 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 08BE3181A47E3 for ; Tue, 28 Sep 2021 07:49:14 +0000 (UTC) X-FDA: 78636206628.01.FEFFE3C Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf26.hostedemail.com (Postfix) with ESMTP id 845A420019C6 for ; Tue, 28 Sep 2021 07:49:13 +0000 (UTC) Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4HJWpC334Dz8tVx; Tue, 28 Sep 2021 15:48:19 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 28 Sep 2021 15:48:58 +0800 Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Tue, 28 Sep 2021 15:48:58 +0800 Message-ID: <5cd6631f-0bac-bd74-3369-1fa4a744687f@huawei.com> Date: Tue, 28 Sep 2021 15:48:57 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 Subject: Re: [PATCH v4 0/3] arm64: support page mapping percpu first chunk allocator Content-Language: en-US To: , , , , , , , , , , CC: References: <20210910053354.26721-1-wangkefeng.wang@huawei.com> From: Kefeng Wang In-Reply-To: <20210910053354.26721-1-wangkefeng.wang@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggeme714-chm.china.huawei.com (10.1.199.110) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 845A420019C6 X-Stat-Signature: wrweqj9n8b9yf7f47683xyqc7k6ezhnz Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=huawei.com; spf=pass (imf26.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com X-HE-Tag: 1632815353-120883 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Catalin and Andrew, kindly ping again, any comments, thanks. On 2021/9/10 13:33, Kefeng Wang wrote: > Percpu embedded first chunk allocator is the firstly option, but it > could fails on ARM64, eg, > "percpu: max_distance=0x5fcfdc640000 too large for vmalloc space 0x781fefff0000" > "percpu: max_distance=0x600000540000 too large for vmalloc space 0x7dffb7ff0000" > "percpu: max_distance=0x5fff9adb0000 too large for vmalloc space 0x5dffb7ff0000" > > then we could meet "WARNING: CPU: 15 PID: 461 at vmalloc.c:3087 pcpu_get_vm_areas+0x488/0x838", > even the system could not boot successfully. > > Let's implement page mapping percpu first chunk allocator as a fallback > to the embedding allocator to increase the robustness of the system. > > Also fix a crash when both NEED_PER_CPU_PAGE_FIRST_CHUNK and KASAN_VMALLOC enabled. > > Tested on ARM64 qemu with cmdline "percpu_alloc=page" based on v5.14. > > V4: > - add ACK/RB > - address comments about patch1 from Catalin > - add Greg and Andrew into list suggested by Catalin > > v3: > - search for a range that fits instead of always picking the end from > vmalloc area suggested by Catalin. > - use NUMA_NO_NODE to avoid "virt_to_phys used for non-linear address:" > issue in arm64 kasan_populate_early_vm_area_shadow(). > - add Acked-by: Marco Elver to patch v3 > > V2: > - fix build error when CONFIG_KASAN disabled, found by lkp@intel.com > - drop wrong __weak comment from kasan_populate_early_vm_area_shadow(), > found by Marco Elver > > Kefeng Wang (3): > vmalloc: Choose a better start address in vm_area_register_early() > arm64: Support page mapping percpu first chunk allocator > kasan: arm64: Fix pcpu_page_first_chunk crash with KASAN_VMALLOC > > arch/arm64/Kconfig | 4 ++ > arch/arm64/mm/kasan_init.c | 16 ++++++++ > drivers/base/arch_numa.c | 82 +++++++++++++++++++++++++++++++++----- > include/linux/kasan.h | 6 +++ > mm/kasan/init.c | 5 +++ > mm/vmalloc.c | 19 ++++++--- > 6 files changed, 116 insertions(+), 16 deletions(-) >