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 F2A34C6FD19 for ; Fri, 10 Mar 2023 09:29:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30DE86B0072; Fri, 10 Mar 2023 04:29:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BCCB6B0074; Fri, 10 Mar 2023 04:29:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15EC56B0075; Fri, 10 Mar 2023 04:29:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 028736B0072 for ; Fri, 10 Mar 2023 04:29:56 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A8CFF1615AE for ; Fri, 10 Mar 2023 09:29:56 +0000 (UTC) X-FDA: 80552466792.15.950BB53 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf18.hostedemail.com (Postfix) with ESMTP id 57EE21C0010 for ; Fri, 10 Mar 2023 09:29:54 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=ROtSz69D; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf18.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678440594; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=36SY5d1GG8v8iH/GYRU2asdPqj5l46qJiLE0fvgiPQE=; b=AjE8ogdVXXDRQja5FaxA30RIfRaBKFg1ldFtAMKkm5krQhgOiCTEnIHQvjW8V+aG5d9Rpf 47uY5fRs69gjPQYlsaXt/Jvwap+Nsv58YMslT5tM2dTValPx8tCNbgur9ZnvJI1ZLDRTuO Mp3hLiYb7ZC1eikeQQNASM5HKN817Ls= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=ROtSz69D; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf18.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678440594; a=rsa-sha256; cv=none; b=EBun4s083tU1pfusVcE629j7enVVBgIPJilE4mVsP4YECoH6wGvJ0CmqruOcqDaiyf4bDw cxJPA10TKZdyeYhULoBZ4CBA3ASPXRAUqFndf3pcUo1loXiLg5egZ1Mamk3/boSYvAVI/3 z4PEkyEaS1peaQy8sVXpn8IC6Ilt+Jk= Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 32A7HTkL013807; Fri, 10 Mar 2023 09:29:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=36SY5d1GG8v8iH/GYRU2asdPqj5l46qJiLE0fvgiPQE=; b=ROtSz69DmgnKhDjvrpKqp6NLk9kHaYATj/TJ4qarm1IPhjpdZHcVsRsrAb41PsDiOt7c 1YTvpO3rhnjKBzpZevkvtlEThWGv+Wt+wyLsPdYtUPWZ9QXVIaPnML8n0aEqu6TQ23zv G5RElkL+T+uS2/uXYefQuBzl6STioOwNQJF4A677VP2lsEh6owdIy/Hx5P29BMF90DbW SZO4byHT5DIEjFSVOcmM0DZ5aUJp4XNBNQkAjB4VYnTaLtmp1jNebHbFu2pFYqU+UCIi aLMjRL+H9ZNln1RzlbFQQ2XOO07uePHoJ4pCbec+xan9Ckd+2AWl6eeOM8BcdfkZ3vP5 0A== Received: from nalasppmta03.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3p7pm11n3c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Mar 2023 09:29:40 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA03.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 32A9TcKP019099 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Mar 2023 09:29:38 GMT Received: from [10.253.32.183] (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; Fri, 10 Mar 2023 01:29:34 -0800 Message-ID: <4dc71eb5-a5eb-d081-a73f-544b63e52537@quicinc.com> Date: Fri, 10 Mar 2023 17:29:31 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v3] mm,kfence: decouple kfence from page granularity mapping judgement Content-Language: en-US To: Kefeng Wang , , , , , , , , , , CC: , , , , , References: <1678413750-6329-1-git-send-email-quic_zhenhuah@quicinc.com> <5251f2a0-95bf-3330-6524-ec5716cc3d29@huawei.com> From: Zhenhua Huang In-Reply-To: <5251f2a0-95bf-3330-6524-ec5716cc3d29@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) 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-GUID: MzIfZmvHY_nEOC4_0bL-AiY66vQ3g7hp X-Proofpoint-ORIG-GUID: MzIfZmvHY_nEOC4_0bL-AiY66vQ3g7hp 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-10_03,2023-03-09_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 adultscore=0 suspectscore=0 clxscore=1011 bulkscore=0 mlxlogscore=999 priorityscore=1501 mlxscore=0 spamscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2303100071 X-Rspamd-Queue-Id: 57EE21C0010 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: kqersrryebmgct44e81ptuikinxygrhp X-HE-Tag: 1678440594-912657 X-HE-Meta: U2FsdGVkX1/Jzhf30cWLVGQnNWdEUNk0bsh+uNF5lIEa2bL7AJnSeyGYlpdc3/14HXxKbCeI2vH2xVTLF/AE9Wswnn4QNoOgzvVsnv9ir2V9gtA2PbIaMenA14jixveaEwyxSgjNxobUr8F2wRaMthsFPPnELciJzZP8cYnMaoAuKcVFifVcITQoWW4RUM63+y5yzrki8lGiEnlHB0eDASJw7ZNCnQK2xnISKGrR+cRmQUldnRHE7UDIDSrwzWeSOYCuQBNemaGGzvgoGqaTtTC+sXi+lDDwwqgczeV+a2cV5ZAU1ISO9XnrJ7+wHbzc7kWEsvPq4/HvpYGiuheQ4bcjUMHI86HIU8iNHWqZF8OStqK058zCkkmQ5rjbtrQ5rZWvR8GzL59WcLulihjJMP20TkDyHHkhO2viLuIy+M2YnVAW3cJljj0BfZcMAw+Pnba1AH7Z12KwxM6I/PWjL7r6hGaUhe9da/gaJl8thwPDdlBUq6NpNUL8s0aACjLTlVcBSANq0MqMlxs4vK3bOUy2AWgrKnw9+O0Ffxzff6O+TXJ9+QcmLjmV2NXsUBvElmpHwMG9c2ATEO2y9XZ1AkJ1IMM92G0LP1C/P655P+93sBPGVIyhYI43OBmx+OilXj/h3wKo2ahlHi59o9+N2Cia2qLUnmtmaPODkZ0fasIiY+HN/IwtdJgGTQakxbVOUxv55WcLhSt8ThgCkyuUGvtg30ULorsrn2Q/YRNCGKK4Jb4EFtvEaMAtVNsTP2xd2jxxvoAg7OTXoJw2EQvhPLQE4HTitEeTi6bFH35QZsUzcX7LJ1oxA3Z138VedOyC+vbR+QzKlGeGg11udlctevamqkxqHIAAAaTleEM+l6TxbMGXoGY4dPAPYdfmY5ijq3ZEz/R3xwmzigJopnkKUhRXOOQT7eZ5pzCGSQ3PtvzLF2DUkE4j2rk+WOWuvaj/XDmWPR7V7w1Aemg8cvE ufdIPvde qxXwrWy2rhOZby8H+nP54p9JKBG+/6H3jd0BHYZB4hLdlgQUQ9XhkFfXkcRQ/xGFRZlEK6WdMD7+4GF5DyiXQ6OanqCCNFLSPFmfQB7MKJnHdfpWgu8oP+EFADudSqD3DVIgyrXZet3Yvnu63b/XYYG2NJc17JEU9G1G8tPw652p/3esVXu6Xmdq2/zuH21qiF+DyVD8XFFRema1Sz+VmJa6sv9CywMX/qsLaRl7GzL/HudhmWS+cZ+DvcXEGShlpbICWXXxSpXwnDQT6NkOSybbNCd1zuYOfSA8lhaDwsYuiUGoOhD7uO8XLBjL364roK+N96L6YEDjRXnGNGFrryRBY4SN4p4lNfjIrj/ciWrr11CNt9BzW2RvZXixT6O0UJQHrUzoziEbcoQ5ggrpboybN6g== 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: Appreciate Kefeng for your review! On 2023/3/10 10:56, Kefeng Wang wrote: > > Hi Zhenhua, > > On 2023/3/10 10:02, Zhenhua Huang wrote: >> Kfence only needs its pool to be mapped as page granularity, previous >> judgement was a bit over protected. Decouple it from judgement and do >> page granularity mapping for kfence pool only [1]. >> >> 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. >> > We do the same way in our 5.10 kernel, a minor comment below, Yeah.. low memory device can benefit from this. > >> LINK: [1] >> https://lore.kernel.org/linux-arm-kernel/1675750519-1064-1-git-send-email-quic_zhenhuah@quicinc.com/T/ >> Suggested-by: Mark Rutland >> Signed-off-by: Zhenhua Huang >> --- >>   arch/arm64/mm/mmu.c      | 44 >> ++++++++++++++++++++++++++++++++++++++++++++ >>   arch/arm64/mm/pageattr.c |  5 ++--- >>   include/linux/kfence.h   |  8 ++++++++ >>   mm/kfence/core.c         |  9 +++++++++ >>   4 files changed, 63 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c >> index 6f9d889..9f06a29e 100644 >> --- a/arch/arm64/mm/mmu.c >> +++ b/arch/arm64/mm/mmu.c >> @@ -24,6 +24,7 @@ >>   #include >>   #include >>   #include >> +#include >>   #include >>   #include >> @@ -525,6 +526,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 = 0; > > The kfence_pool is no need to be initialized. Done > >> + >> +    if (!kfence_sample_interval) >> +        return (phys_addr_t)NULL; > > And one more missing case, kfence support late int, see commit > b33f778bba5e ("kfence: alloc kfence_pool after system startup"), > this changes will break this feature, we add a new cmdline to alloc > kfence_pool regardless of kfence_sample_interval value, maybe there some > other way to deal with this issue. Yeah, Thanks for reminder. It seems we need only to avoid the case which allocating pool later. kfence_pool also seems only to be allocated once, and once allocated, will not be freed any more. So how about we raise another change, like you mentioned bootargs indicating using feature of b33f778bba5e ("kfence: alloc kfence_pool after system startup"). 1. in arm64_kfence_alloc_pool(): if (!kfence_sample_interval && !bootargs) return 0; else allocate pool 2. also do the check in late allocation,like if (do_allocation_late && !bootargs) BUG(); > >> + >> +    kfence_pool = memblock_phys_alloc(KFENCE_POOL_SIZE, PAGE_SIZE); >> +    if (!kfence_pool) { >> +        pr_err("failed to allocate kfence pool\n"); >> +        return (phys_addr_t)NULL; > > no need this return; Done > >> +    } > >> + >> +    return kfence_pool; >> +} >> + >> +#else >> + >> +static phys_addr_t arm64_kfence_alloc_pool(void) >> +{ >> +    return (phys_addr_t)NULL; >> +} >> + >> +#endif >> + > > I like all of '(phys_addr_t)NULL' to 0 I've tried, yeah, seems no warning. Updated. > >>   static void __init map_mem(pgd_t *pgdp) >>   { >>       static const u64 direct_map_end = _PAGE_END(VA_BITS_MIN); >> @@ -532,6 +560,7 @@ static void __init map_mem(pgd_t *pgdp) >>       phys_addr_t kernel_end = __pa_symbol(__init_begin); >>       phys_addr_t start, end; >>       int flags = NO_EXEC_MAPPINGS; >> +    phys_addr_t kfence_pool = 0; > > it's no need to be initialized too. Done > >>       u64 i; >>       /* >> @@ -564,6 +593,10 @@ static void __init map_mem(pgd_t *pgdp) >>       } >>   #endif >> +    kfence_pool = arm64_kfence_alloc_pool(); >> +    if (kfence_pool) >> +        memblock_mark_nomap(kfence_pool, KFENCE_POOL_SIZE); >> + >>       /* map all the memory banks */ >>       for_each_mem_range(i, &start, &end) { >>           if (start >= end) >> @@ -608,6 +641,17 @@ static void __init map_mem(pgd_t *pgdp) >>           } >>       } >>   #endif >> + >> +    /* Kfence pool needs page-level mapping */ >> +    if (kfence_pool) { >> +        __map_memblock(pgdp, kfence_pool, >> +            kfence_pool + KFENCE_POOL_SIZE, >> +            pgprot_tagged(PAGE_KERNEL), >> +            NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS); >> +        memblock_clear_nomap(kfence_pool, KFENCE_POOL_SIZE); >> +        /* kfence_pool really mapped now */ >> +        kfence_set_pool(kfence_pool); >> +    } >>   } > Addressed above comments, I've raised V4 patchset, please help review:)