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 X-Spam-Level: X-Spam-Status: No, score=-12.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00AA9C433DB for ; Thu, 4 Feb 2021 06:33:09 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8ED5264F4D for ; Thu, 4 Feb 2021 06:33:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8ED5264F4D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/e9NZ3kW/KTUUznKBGBr6PZZtqSH+UEbXxqEpbVIRGk=; b=hidb9d3OoiX10Oa2RGkRwJxOZ ZBls+LyXEvlKSYUFhV4LYV/e1JL+0GlTV7lx+6RSoX/G75q8tjc5ffKcmlabOnQk5IY0NXlfLx5S6 6RTIMQRB8j0Hl5S9f1/zjdYdHXOpEUllx5X5xowqsgNALEE7cLiNY3pwqH4vUDnaoSrIuG6DSp3tV 8kCv2ysqCzAsiJlY8ddVmitT1phoZHq3rK3HhnCsFLaHJVXEUlbrF3IFvMwHOvr7xf6W+wlO4MtRY EfSVevi9Rli2lgMzkwlvfV1CKnhbZGBvaWNaO0YwT82ppbMyn1F5PsPiRVxtnYFBxuzJ33VK48pK0 XMmMLjMbQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7YBI-0000im-I0; Thu, 04 Feb 2021 06:31:56 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7YBG-0000ho-DQ; Thu, 04 Feb 2021 06:31:55 +0000 X-UUID: e2c3110a6e404694813337af24eb2a23-20210203 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=gWpJFZlypYrBJ7tV7aTC4UBUDp2mEuIrSdqhe2L5ZuI=; b=RvoRG2v+lFvLf+d1UTV7TxZ3mk4iZXKytZH9tWw0F+XRVtsTuTrecFymJHnwxbxHgp9+BhIyNw0ChsulnirBWUkqGaiR5vd+4CtRNdGcoEzHgy5jE/JMdPHLlAzhviuX+9kvRP/COY4srGd7hEHXH5ZUh3EVVsrgoMM/cBoY1s8=; X-UUID: e2c3110a6e404694813337af24eb2a23-20210203 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1827225803; Wed, 03 Feb 2021 22:31:48 -0800 Received: from mtkmbs05n2.mediatek.inc (172.21.101.140) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Feb 2021 22:21:40 -0800 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkmbs05n2.mediatek.inc (172.21.101.140) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Feb 2021 14:21:38 +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; Thu, 4 Feb 2021 14:21:38 +0800 From: Lecopzer Chen To: Subject: Re: [PATCH v2 1/4] arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC Date: Thu, 4 Feb 2021 14:21:28 +0800 Message-ID: <20210204062128.27692-1-lecopzer.chen@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: References: MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210204_013154_721890_A836588D X-CRM114-Status: GOOD ( 15.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: lecopzer.chen@mediatek.com, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, tyhicks@linux.microsoft.com, glider@google.com, vincenzo.frascino@arm.com, will@kernel.org, yj.chiang@mediatek.com, kasan-dev@googlegroups.com, dvyukov@google.com, aryabinin@virtuozzo.com, linux@roeck-us.net, andreyknvl@google.com, lecopzer@gmail.com, broonie@kernel.org, linux-mediatek@lists.infradead.org, dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org, gustavoars@kernel.org, akpm@linux-foundation.org, robin.murphy@arm.com, rppt@kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > On Sat, 9 Jan 2021 at 11:33, Lecopzer Chen wrote: > > > > Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 > > ("kasan: support backing vmalloc space with real shadow memory") > > > > Like how the MODULES_VADDR does now, just not to early populate > > the VMALLOC_START between VMALLOC_END. > > similarly, the kernel code mapping is now in the VMALLOC area and > > should keep these area populated. > > > > Signed-off-by: Lecopzer Chen > > > This commit log text is a bit hard to follow. You are saying that the > vmalloc region is *not* backed with zero shadow or any default mapping > at all, right, and everything gets allocated on demand, just like is > the case for modules? It's much more like: before: MODULE_VADDR: no mapping, no zoreo shadow at init VMALLOC_VADDR: backed with zero shadow at init after: MODULE_VADDR: no mapping, no zoreo shadow at init VMALLOC_VADDR: no mapping, no zoreo shadow at init So it should be both "not backed with zero shadow" and "not any mapping and everything gets allocated on demand". And the "not backed with zero shadow" is like a subset of "not any mapping ...". Is that being more clear if the commit revises to: ---------------------- Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END. Before: MODULE_VADDR: no mapping, no zoreo shadow at init VMALLOC_VADDR: backed with zero shadow at init After: VMALLOC_VADDR: no mapping, no zoreo shadow at init Thus the mapping will get allocate on demand by the core function of KASAN vmalloc. similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated. -------------------- Or would you have any suggestion? Thanks a lot for your review! BRs, Lecopzer _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel