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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DF20C6FD1F for ; Tue, 14 Mar 2023 08:37:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C92FC8E0003; Tue, 14 Mar 2023 04:37:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C434A8E0002; Tue, 14 Mar 2023 04:37:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B0A808E0003; Tue, 14 Mar 2023 04:37:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9F4E08E0002 for ; Tue, 14 Mar 2023 04:37:14 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7080CAB735 for ; Tue, 14 Mar 2023 08:37:14 +0000 (UTC) X-FDA: 80566849188.09.378C294 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf01.hostedemail.com (Postfix) with ESMTP id 555EC4000B for ; Tue, 14 Mar 2023 08:37:11 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=ZFrEdbrt; spf=pass (imf01.hostedemail.com: domain of quic_pkondeti@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_pkondeti@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678783031; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=C84AymT5YACNpIpMYeYeDQHf7rfGkELQaUTQMnPM7QM=; b=xG3AcjzI94vb8oc7xBYZOtPyK0hNtrEkj/HMcL7E0LxLmpeC0rLm056aZalTmE4CHNQ2cV uIoFjplwnQS7X7qg/s2LEuoyv/Wu7ePfaLDVpAjrcYnmqy1VNkXIXHzFm+Ag836Z5zgQzF +Q6wxDdy2o0g1f+mtzZIi+Vmm11nUTE= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=ZFrEdbrt; spf=pass (imf01.hostedemail.com: domain of quic_pkondeti@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_pkondeti@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678783031; a=rsa-sha256; cv=none; b=00v1MQ3I0+XuqkXrXEeInl0V8MjbouEyiaPj5ZsNtzBtIR6B3FPYWjM4wJRU5b4Rrxopl8 1CsXddpGTw78CJET+3nsMND382O9EzamLlD535zKAiRtyI7vhbrneIVxhEV56qefRxAcda eaW78XaIiIDs8ZsOyJtcdedcUWDEAaU= Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 32E3X9vB012826; Tue, 14 Mar 2023 08:36:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=qcppdkim1; bh=C84AymT5YACNpIpMYeYeDQHf7rfGkELQaUTQMnPM7QM=; b=ZFrEdbrtyi22dax3QvX0MvWue7iL3EwgJQGyny/QGddVHd+OHX2KIqZp2FgPu9Q0dGN6 yxnAo6XGmigKDDVM2OzFFdVI7HKFiEcMGBiSRxnp2tkz3q6ywCsLia8LFva/COgjXZsw 5FJyROh/LSObHo+IGwe5P6MGOFiADUFYzvL5CX8a3Sp81Z+T+bJhvxlHei6Sh5rx4bK1 YDhYAg6nULLjELZEy66X05SoA/nRgllbmGT+bWYozCJAJalFc7C1Ke/L1gD9FLi0SOHd hTpiOmiGWCJZ0iJbQS/R++1qCgmlzqXYsRq82/OLLzCXPLGbgyV1UdvES6cOSd5M2T+z fA== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3pa6n32ark-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Mar 2023 08:36:56 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 32E8atuQ012235 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Mar 2023 08:36:55 GMT Received: from hu-pkondeti-hyd.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.41; Tue, 14 Mar 2023 01:36:49 -0700 Date: Tue, 14 Mar 2023 14:06:45 +0530 From: Pavan Kondeti To: Zhenhua Huang CC: , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v8] mm,kfence: decouple kfence from page granularity mapping judgement Message-ID: <20230314083645.GA556474@hu-pkondeti-hyd.qualcomm.com> References: <1678777502-6933-1-git-send-email-quic_zhenhuah@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1678777502-6933-1-git-send-email-quic_zhenhuah@quicinc.com> X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: gQ5B3sSY4clGrGX4snFkxFU3scPb7nQ- X-Proofpoint-GUID: gQ5B3sSY4clGrGX4snFkxFU3scPb7nQ- X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-03-14_02,2023-03-14_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 mlxscore=0 bulkscore=0 mlxlogscore=878 impostorscore=0 priorityscore=1501 adultscore=0 phishscore=0 spamscore=0 lowpriorityscore=0 clxscore=1011 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2303140073 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 555EC4000B X-Stat-Signature: omyp8i3qi91bbx5we8tqf88huwi54kdg X-HE-Tag: 1678783031-310421 X-HE-Meta: U2FsdGVkX18QXAeZOnIbjFoW+Ff+asdWQIq6wZ2vBxaqVXp9WRi/M3cauY6OfWU5BrH9mBcpFnIgaxobTWOzydPlHELrL5Ab0vzxgQHvzJdgdWAg5zbpv46QtvnAYuEfORBLishJ5wx/EujgV7EBjFDmYOUFEtYeW4ayrcUNauCZsx81gMNmz1gNczwB6FUu9mGVgQf5oxhYM1HnwxYr4haXOfQsAnIkYtZ9MoaOkWR7XQOHK/mXRcLCqSqIax4b54UVQP9g4WXOxNeeEhN9yk68wI0a744wj0rZrp+jHn/EoUFqfRtAtg90HnLUeKkR51JTnNFZ+4OcbtTTzLT222yWZCRex5pGDPURmdZog6UZkZ1Ykc8dtBdoMjqTsgIQvGH9dPl0A3qKL3BMbnPrSJeuvv145q+vo5AmRO6/P1BSE01T8/CyQ6KwqD1eCl9hG8kwb4sykH1TFGfIiHkWzKNVQx4BqxilYko+1SlN8lvphrcunuRyTqE2FQpKhArEBk5bvFUiqILZZPljOuT6tQzYlJT8s9DTA4FU0fsWQBMRxnTplAO6DKOpGiOF0B3+1UZjmOo+6nIf95vwyAFnxq9JqdBEbDTDgzF7SorIwAx93oGnOdjGLuGHz+V/QVwW2Lr08bs9PzDy55x7uHAQNz0gpOK3vWGNADGgoYgCMN9f6m7ITc9MIPyw+cRdFsFDh80xtl98AoTVc5053XI5WL4GPnr13R71mNBOTcvoekKwIpR0k5grmDfjR+7fXW2K4rEr02lNps0LS4oIn/3iUylwLt0mY8bnHdGbjRC0Pa43TUHpnTKBHqHPpqIIAywjUxJWs+5GZ5+YqUNgKvhzowFN6wLf1o3Irz9tyaKjHOwrSo4HU9S1qIf81dwqCOyzzCQocTPuTNR+3UGv/RWFDCR6SjJxILWjATy3ydRcH+ZJJHY/FkcAphTMi7p5ryxbAakp5xhNEO6Tp5qMhOl kjIQYht8 mkguACbXAgs5WpFqKR3xhCKRI2kAsuSucgcnxJb3oMlJh2eKJJ+BhO9Lob0eizDn+CtZhnxilbrpWtHmXqEWRSJA4eIklCbrcu5ht2ccYAkQWgVw0sLdDbbg0EZf2GcS/P7IX3Va/kfC+mUVSmEufb2JNSHxHGvuA/5MvJzxkKIVzBkzPtQ0iQKorerYYKJTdwGrOkVN9VVm04mfGvzdwDbzmgsIRc7HJmom2aSjXjO+fz/3pw9wxuJfk2Bd8Wzr/LC/4lDb+7656qnvaNyDzKtQCmOSJ9IvPxAr7fCI9UmdV3Cv6EoDeBtEA0P5M9/0wx+FuYSUl7o221J8YsCy/0lk5D8sFmQ3ZY2WzKxiwfNVIO5RHO4KM1CpT2Odokek9kHuaZM7Xt/sGiSAn87XtBhmhAQ== 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: On Tue, Mar 14, 2023 at 03:05:02PM +0800, Zhenhua Huang wrote: > Kfence only needs its pool to be mapped as page granularity, if it is > inited early. Previous judgement was a bit over protected. From [1], Mark > suggested to "just map the KFENCE region a page granularity". So I > decouple it from judgement and do page granularity mapping for kfence > pool only. Need to be noticed that late init of kfence pool still requires > page granularity mapping. > > Page granularity mapping in theory cost more(2M per 1GB) memory on arm64 > platform. Like what I've tested on QEMU(emulated 1GB RAM) with > gki_defconfig, also turning off rodata protection: > Before: > [root@liebao ]# cat /proc/meminfo > MemTotal: 999484 kB > After: > [root@liebao ]# cat /proc/meminfo > MemTotal: 1001480 kB > > To implement this, also relocate the kfence pool allocation before the > linear mapping setting up, arm64_kfence_alloc_pool is to allocate phys > addr, __kfence_pool is to be set after linear mapping set up. > > LINK: [1] https://lore.kernel.org/linux-arm-kernel/Y+IsdrvDNILA59UN@FVFF77S0Q05N/ > Suggested-by: Mark Rutland > Signed-off-by: Zhenhua Huang > --- > arch/arm64/include/asm/kfence.h | 2 ++ > arch/arm64/mm/mmu.c | 44 +++++++++++++++++++++++++++++++++++++++++ > arch/arm64/mm/pageattr.c | 9 +++++++-- > include/linux/kfence.h | 8 ++++++++ > mm/kfence/core.c | 9 +++++++++ > 5 files changed, 70 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/kfence.h b/arch/arm64/include/asm/kfence.h > index aa855c6..f1f9ca2d 100644 > --- a/arch/arm64/include/asm/kfence.h > +++ b/arch/arm64/include/asm/kfence.h > @@ -10,6 +10,8 @@ > > #include > > +extern phys_addr_t early_kfence_pool; > + > static inline bool arch_kfence_init_pool(void) { return true; } > > static inline bool kfence_protect_page(unsigned long addr, bool protect) > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index 6f9d889..7fbf2ed 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -38,6 +39,7 @@ > #include > #include > #include > +#include > > #define NO_BLOCK_MAPPINGS BIT(0) > #define NO_CONT_MAPPINGS BIT(1) > @@ -525,6 +527,33 @@ static int __init enable_crash_mem_map(char *arg) > } > early_param("crashkernel", enable_crash_mem_map); > > +#ifdef CONFIG_KFENCE > + > +static phys_addr_t arm64_kfence_alloc_pool(void) > +{ > + phys_addr_t kfence_pool; > + > + if (!kfence_sample_interval) > + return 0; > + Are you sure that kernel commandline param are processed this early? AFAICS, start_kernel()->parse_args() process the kernel arguments. We are here before that. without your patch, mm_init() which takes care of allocating kfence memory is called after parse_args(). Can you check your patch with kfence.sample_interval=0 appended to kernel commandline? > + kfence_pool = memblock_phys_alloc(KFENCE_POOL_SIZE, PAGE_SIZE); > + if (!kfence_pool) > + pr_err("failed to allocate kfence pool\n"); > + For whatever reason, if this allocation fails, what should be done? We end up not calling kfence_set_pool(). kfence_alloc_pool() is going to attempt allocation again but we did not setup page granularity. That means, we are enabling KFENCE without meeting pre-conditions. Can you check this? > + return kfence_pool; > +} > + Thanks, Pavan