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 06EA3C61DA4 for ; Thu, 9 Mar 2023 15:39:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 96BB76B0071; Thu, 9 Mar 2023 10:39:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 91C29280002; Thu, 9 Mar 2023 10:39:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7BD6F280001; Thu, 9 Mar 2023 10:39:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 68EC26B0071 for ; Thu, 9 Mar 2023 10:39:06 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A66BCA0FAD for ; Thu, 9 Mar 2023 15:39:03 +0000 (UTC) X-FDA: 80549768166.30.93A8B9C Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf09.hostedemail.com (Postfix) with ESMTP id F1AD9140016 for ; Thu, 9 Mar 2023 15:39:00 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=KAllfzh2; spf=pass (imf09.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@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=1678376341; 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=AYIRtoWFboOFtBFZyeFYqp6QnxOiw1kg1yPvAfxdN+c=; b=NjElKeU9KsvbjDSpqvq8qPi9f9e5JfcwjJlqMr9Bug5asolkcdF3kjhMh10bkDgOWTXh56 GHDANbCIBJe5/If+63ScuNGc+MLMImUX2Y9XmbnrtpvrYflZVbHS/O3lU+RegYZXrrQ9EL Fo22y7Rf7/kpInn3Yr8yc+4Amvc5F1Y= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=KAllfzh2; spf=pass (imf09.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678376341; a=rsa-sha256; cv=none; b=mgR8kL7ZqOdfc1b/syfaeOuEXNfxIiKPvZVVAzWL3aHaYZ2dYV0wJeu086OC3tlgd/Nh6C +ye8aTej135mlTVJmU0hb4XmwAI+iMfCZnwv2CUzjiC67mqwhpBYIt4P1RumwPLtDk174N Uh+Jlem2pRBUKD38jlxckdAr5V3Pn3c= Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 329C67bt007017; Thu, 9 Mar 2023 15:38:53 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=AYIRtoWFboOFtBFZyeFYqp6QnxOiw1kg1yPvAfxdN+c=; b=KAllfzh2gaFwQFbJvUJ7LwQ0V3APAKCzg/oEeyRokSQIFLoqP3jVdnBwRhxrq0jErU/N 8GkIR0N8eZlSLTnNzLePqmj6bipyBlROyJ7Duk4B1AZeoK3Mj/rHKLSTYLXh7/o8Am6Y JFGaMD6ApA2J1OCQy8UGZcDTJkPPQfR3hQRmpdyZuTBn+8iwOtmB8yaGYurUImFVKM60 J93m7oggP7AWywP9G3Vw+DclT1BwCYibO3DBsdHAnxESKOqdMX80P1DgFeTOSQVDT2LR gFiGJ8fTUEBuVm1EVpUoB2ALhdovCKN7GPAYq1RE0KGI4n0ky9L2wq6W/HVire31NnzK gQ== Received: from nalasppmta03.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3p6vrmuetp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Mar 2023 15:38:52 +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 329FcpHJ023219 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Mar 2023 15:38:51 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; Thu, 9 Mar 2023 07:38:47 -0800 Message-ID: <9142bfe9-4ec8-13fe-7e19-fd35821afe8f@quicinc.com> Date: Thu, 9 Mar 2023 23:38:44 +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] mm,kfence: decouple kfence from page granularity mapping judgement Content-Language: en-US To: Marco Elver CC: , , , , , , , , , , , , , , References: <1678349122-19279-1-git-send-email-quic_zhenhuah@quicinc.com> <706340ef-1745-c1e4-be4d-358d5db4c05e@quicinc.com> <3e8606e4-0585-70fa-433d-75bf115aa191@quicinc.com> From: Zhenhua Huang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit 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: WWtGiyOMv62IvZBRtJdgWj_45yDmXOG1 X-Proofpoint-GUID: WWtGiyOMv62IvZBRtJdgWj_45yDmXOG1 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-09_08,2023-03-09_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 bulkscore=0 mlxscore=0 malwarescore=0 suspectscore=0 adultscore=0 phishscore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 impostorscore=0 mlxlogscore=849 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2303090123 X-Rspamd-Queue-Id: F1AD9140016 X-Stat-Signature: 5soocrhu63em9ofsu4pa7u1fqynh38pi X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678376340-207580 X-HE-Meta: U2FsdGVkX1+xnlMA7iNlsQ0EU5Ekysul3o3/xaHM6JMvYiL3A2GnFt/qRS7IW9rc7X380e3OrZGPu17fa8uABxj7NbkynE9N3FMuzdIsb5WAclHBTo/JeKQcI1rB05TWfD0jSF7O/M6U3umrOcj5bAvPqE6nQUSD1hlZb1kREI9XG3fr7vQXBis2xx12S219gBpbpUWKRoiILKrNTw3wY7MF5VYzl++95DTG2+tBWc5ApNOUzUTOVdViiePUZNTekRaNeOc/wMNs1OJ1BrCeDmpK6ZgE+dtl5TXGja5BQxQ7rhES3pnA2wGyDMgP7+VxrWHS24Ko/fOk0jYeTIUslSvYZFcX+5DhtSX9UXhix5XpV2xeJ8hijVPabcAXMGkZ4jPpzSSXiI2Fhmzx2PPy7prN52BwCgXUHPep0GfXiZ3OuzV3lJhsKJn7x8XPzvmK/D2hWg4ykYfZQaFj6A23rbHa/h1RrhGUaC08+2FmuLF5BoJZTykuQfjhnN1zoRY1X0KxnbdIpR4lGV3vuB8yc+8MK109gTLJBMfrjvNpXMgnqRYoASu+7MoYgQc898TBVT2Um+M8sWu1+76eCvgBwmyYsnCxUgJ4rkaBys/6rG+H+uQkKH82cFq7DRQUR0li5tT5LDcqrSiRAQQXhz4PpDRdWg9ODJOuV2rsWw4YJZ7IsZ4sXAUDC7FZ/ptGKCcNQctA2p/cwgPSNqEbA/+vz0lfedLrg7aTyiC/Eli7YmFwLakSJs9LhePvF0ghBBsF8GGajPyERCf2lKul91amTQltpAsVAqTt18z6l8s9VIbooTLc3XZ6cf/TMg5kv2kcb0M6VMTg0XiplYoee6PW+zDM5LnNnQLtBXl0btdO5ke/G4+yW3KsTwswvCl8HXb928gtqt428dXqiDehU+RWmAWmp2d+YX8RrEVFs4MCAUWl5v4m7Xgw+4zXGUrVQLITQwlamj6JTTB/L1E9TPv 9wmRCV9G Ag0F24PewGN1KuExB7fV2e5oW2nxAjrW1wrT8x8TqIY/scP1eXR1MwnlXkHrAFHjFih8HobW9/TmHxp2eC38CgTak0hbf9mOtjhxlXGalcAmtfYTqkC4TRj0HTiDFv6uKxl3iwo7DrqonRe0lS1yfDG9xtI3P0G8n7USXIVV8A5WVVha81dDivYTrOSgNL9hoGHD6R1oXwHaQdMX73GkzT9APrwh5cGUODUPYCSmVU0ceRIMgI6+DcPVe0bR8IO9nd28PRu5rQPe0wEb3nm8yLCe4tA== 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 2023/3/9 19:38, Marco Elver wrote: > On Thu, 9 Mar 2023 at 12:26, Zhenhua Huang wrote: > [...] >>> Ah right - well, you can initialize __kfence_pool however you like >>> within arm64 init code. Just teaching kfence_alloc_pool() to do >>> nothing if it's already initialized should be enough. Within >>> arch/arm64/mm/mmu.c it might be nice to factor out some bits into a >>> helper like arm64_kfence_alloc_pool(), but would just stick to >>> whatever is simplest. >> >> Many thanks Marco. Let me conclude as following: >> 1. put arm64_kfence_alloc_pool() within arch/arm64/mm/mmu.c as it's >> arch_ specific codes. >> 2. leave kfence_set_pool() to set _kfence_pool within kfence driver, as >> it may become common part. >> >> The reason we still need #2 is because _kfence_pool only can be used >> after mapping set up, it must be late than pool allocation. Do you have >> any further suggestion? > > I don't mind kfence_set_pool() if it helps avoid some #ifdef CONFIG_KFENCE. > > However, do note that __kfence_pool is exported from > include/linux/kfence.h. Since you guard all the new arm64 code by > #ifdef CONFIG_KFENCE, kfence_set_pool() doesn't look necessary. > However, if you do something like: > > #ifdef CONFIG_KFENCE > ... define arm64_kfence_alloc_pool ... > #else > ... define empty arm64_kfence_alloc_pool that returns NULL ... > #endif > > and make that the only #ifdef CONFIG_KFENCE in the new arm64 code, > then you need kfence_set_pool(). I think that'd be preferable, so that > most code is always compile-tested, even if the compiler ends up > optimizing it out if it's dead code if !CONFIG_KFENCE. Thanks Marco, good suggestion. I've done like this: only one CONFIG_KFENCE now in arch/arm64/mm/mmu.c. I also tested w/ both CONFIG_KFENCE and !CONFIG_KFENCE. Please help review v2 patch :) > > Thanks, > -- Marco