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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C47DBC433F5 for ; Sun, 13 Feb 2022 16:07:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236982AbiBMQHQ (ORCPT ); Sun, 13 Feb 2022 11:07:16 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:35972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236379AbiBMQHO (ORCPT ); Sun, 13 Feb 2022 11:07:14 -0500 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 626545A0A4 for ; Sun, 13 Feb 2022 08:07:04 -0800 (PST) X-UUID: 7c26e1c48cb240c78db72cdf8cb77316-20220214 X-UUID: 7c26e1c48cb240c78db72cdf8cb77316-20220214 Received: from mtkcas10.mediatek.inc [(172.21.101.39)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 757746491; Mon, 14 Feb 2022 00:06:57 +0800 Received: from mtkexhb02.mediatek.inc (172.21.101.103) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 14 Feb 2022 00:06:56 +0800 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkexhb02.mediatek.inc (172.21.101.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Feb 2022 00:06:56 +0800 Received: from mtksdccf07.mediatek.inc (172.21.84.99) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 14 Feb 2022 00:06:56 +0800 From: Lecopzer Chen To: CC: , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v2 1/2] arm: kasan: support CONFIG_KASAN_VMALLOC Date: Mon, 14 Feb 2022 00:06:56 +0800 Message-ID: <20220213160656.17605-1-lecopzer.chen@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus Thanks for your review. > > - kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START), > > + if (!IS_ENABLED(CONFIG_KASAN_VMALLOC)) > > + kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START), > > + kasan_mem_to_shadow((void *)VMALLOC_END)); > > + > > + kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_END), > > kasan_mem_to_shadow((void *)-1UL) + 1); > > Where is this actually mapped? > > Can you print out where > kasan_mem_to_shadow((void *)VMALLOC_START) > kasan_mem_to_shadow((void *)VMALLOC_END) > as well as KASAN_SHADOW_START and KASAN_SHADOW_END > points? > > When I looked into this getting the shadow memory between > KASAN_SHADOW_START and KASAN_SHADOW_END > seemed like the big problem since this is static, so how is Kasan > solving this now? For quick answer: As I knwon, the definition of KASAN_SHADOW_START and END (@arch/arm/include/asm/kasan_def.h) * 1) KASAN_SHADOW_START * This value begins with the MODULE_VADDR's shadow address. It is the * start of kernel virtual space.... * * 2) KASAN_SHADOW_END * This value is the 0x100000000's shadow address: the mapping that would * be after the end of the kernel memory at 0xffffffff.... and the virt address of vmalloc for ARM32 is also between MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), so nothing needs to do. If there is any cases may break this assumption, please correct me, thanks. > > Please patch the picture in > include/asm/kasan_def.h > and the info in > Documentation/arm/memory.rst > so it clearly reflects where VMALLOC is shadowed. Thanks for suggestion, Yes, we really do need to update doc for memory layout. I'll study how to add it and provide in v3.