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 58164C74A4B for ; Mon, 13 Mar 2023 10:27:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4A426B0071; Mon, 13 Mar 2023 06:27:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFA0C6B0072; Mon, 13 Mar 2023 06:27:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C2E26B0074; Mon, 13 Mar 2023 06:27:37 -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 8E3466B0071 for ; Mon, 13 Mar 2023 06:27:37 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5411D8090B for ; Mon, 13 Mar 2023 10:27:37 +0000 (UTC) X-FDA: 80563498554.11.D353CAD Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf01.hostedemail.com (Postfix) with ESMTP id 17EF140014 for ; Mon, 13 Mar 2023 10:27:34 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=bOlAGVk7; spf=pass (imf01.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=1678703255; 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=rofOjC9A+Ai///mQWL9wVXqOvBS/3fDbNXwUVpk+DCQ=; b=pKH/+404D2/RvkZAFAPrkm+pTftTm0fN6XKJIhK5blmhShqM19yMDaBr1w3Ge2zG8DnIyT hTeGxRCAZGqDLaKyCOWIMY4AxxhvcuFme/YN77Vkx7PSij7ICg+MmyVHitcPYdt6q3Z1i4 H+rQeO/Gs8Yt+TcB1a2crwN0MdTK3qY= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=bOlAGVk7; spf=pass (imf01.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=1678703255; a=rsa-sha256; cv=none; b=q7AepF5YtcQb5JjO9/iLLXHTXbebRcNo+foxtwo9lvll14FI4DkT+am99ksmO53o0tWeX0 cJUijeVlgn4124rOjRVsS0mkYtAcWi4vkg00UofEmajtaY/eYeD/z1BG3Z6WjF/tAVUPmt sgL/qCVN5yojlirjQzbjEraSkzMcvIE= Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 32D9fAAb008657; Mon, 13 Mar 2023 10:27:23 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=rofOjC9A+Ai///mQWL9wVXqOvBS/3fDbNXwUVpk+DCQ=; b=bOlAGVk7Eh4ji8q4qRex71y5OiJeKGHPQk64SjlrGzEzn+4FeR+ZkmE7UbG5EmKPn0IP HL77pOcivAFMG9Q5q9XlGPr4FIBDDBVdXapRvlkpNeuFHDCewp6nXtGT27Mx5zqi9zf4 NAv3MRuntH+KqvYTdreF+HIEbSDnCUUs96tiG58m9O/y+ATqoYj1wpYDEdV8OJi1Dkf/ mOPi9fhtojUY0/At5Nh8+zjI+B6rGDpf2vdHMNjvbxva1Y8G6xYUzYZSXEHNV6ndALOd GnjUpSX+DXnRaZZBlc6KcCB6fwoq5lXSnt/q+A4mmgh4bhgWWAkTtnKixUXZaNTrcTy9 cQ== Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3p8gysve4e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Mar 2023 10:27:23 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 32DARLFM004777 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Mar 2023 10:27:21 GMT Received: from [10.239.132.245] (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; Mon, 13 Mar 2023 03:27:17 -0700 Message-ID: <148243e5-8dfb-4094-9ebc-b221e2e9c01f@quicinc.com> Date: Mon, 13 Mar 2023 18:27:15 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v5] mm,kfence: decouple kfence from page granularity mapping judgement Content-Language: en-US To: Marco Elver CC: , , , , , , , , , , , , , , , References: <1678683825-11866-1-git-send-email-quic_zhenhuah@quicinc.com> <8b44b20d-675c-25d0-6ddb-9b02da1c72d2@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-GUID: l6wPTF02mlGoWqbaOAXACTGE-pIo_OOi X-Proofpoint-ORIG-GUID: l6wPTF02mlGoWqbaOAXACTGE-pIo_OOi 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-13_02,2023-03-10_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 suspectscore=0 adultscore=0 phishscore=0 priorityscore=1501 clxscore=1015 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2303130084 X-Rspamd-Queue-Id: 17EF140014 X-Stat-Signature: ppjxxbzyoe46hkxdqfte7yw6h78s5zmf X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678703254-793952 X-HE-Meta: U2FsdGVkX19r8ZIJQD5uUrXnVdLb9WhorV7dL/ZVxBIQ/6JlrGsJTsOaVJLpGItXNn2chM62B+GGpE55uIdxn+Dqs60uNXVbE5zL4580l1LFFttOShiRHudUGiZGxIRGgxQITIfIoGqAKn/d7ilwHfYFExKXdD8NwCIanPorQF1LMv4myrGR+HAG1WeqDCya+UdMzwQ8JP4Enp0XQFHJJ37uaX3vX7k3DW11meU1MyDt/jOJKX3qrhMyOUaTvPEIDWjQRyqBtSQfZj8hh7dzyJYlfwUm4wwVSCbmuIjtIIs2zodjm/BYId1dmBCoZEMQcdjKkSXzY5dDfPwIvduvDtHSx0n8IYHqovZGUVhg8yGz7p+n6RG2cblf258tXfZc1jn35tlP+wnyZin/w7tGz9NIzLr6FR+lSl0CL0+IzqFXxGv/V3jrgY9BM/8GKr5quIMFownR8MWxaw+jqlaDwYMSO8gH7QmEHOvmsszsZjiGruXXff72GUEJRQahrYtwD62D2cn6m5dYxzUwzQ1HoMxqg/slC8IiCqnPdn8R10ZcTQxsbp1wNG4g2v3evrBxpSMC+DZSu09SLOCfBu/CVFwb7Uim1A1upKWGz0jKLE38i347PceiZp5/ucGNtW5taA3jd8cin7vhX5PpKEE/R5VhHFDIloatgbgFcDDIIF+5D2PX5VJ3KUDbE7fOBAtM/wYuKb++TvwQzviSDfn2Pr7cPYvfq6WSiXbRxfJK4YCTOamRK+5i6J7cGBAInuX16MAf4iWHW1wrLwMKsftmn2vn1BaOtEtinUc55geArPR4m0+X/EyqQjAS1c7KBYxCQICQhbGHBMHKaGIO6MmMeYRBYxle0rjzW24fcYIhlmy5ClldxClap1i4N1r78NSdNWC4kJ5kHq+EI1lhJ53aWyUzIiFMwrzt8gAdh3NUoat1UzBenjnIaZnvYSsbrA5FBCfNv4DSm9MKglT3W/y k0Jla4tB 4WyINesgGmBfl/Q87oMS1A3XgJ3kh+p5CC254eX/Bfb2KsSs3qZheFyGwIwLvjTvWLGZYMhvZ5i3d2jVKAyRzrZPMyJ/aDL45aWR9pcEOdxew6pwSF7FDAC4gnueWreW206LCY3m3A3v7yxg8yYRZmBzCvkPzySMsFLKbPtAN+8cCK0px0KCp2cCa/8Y5whe0tm6tmaS8kIOje0wp+760hVp5H0kM0FlxJUp98fiWodMl+wzvMjz3PCgFFTIV8b79r8VEGfoKoIQuTehb1ZO958iQAkbegNAlGH1G 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: Thanks Marco! On 2023/3/13 17:49, Marco Elver wrote: > On Mon, 13 Mar 2023 at 10:05, Zhenhua Huang wrote: >> >> Thanks Marco! >> >> On 2023/3/13 15:50, Marco Elver wrote: >>> On Mon, 13 Mar 2023 at 06:04, Zhenhua Huang wrote: >>>> >>>> Kfence only needs its pool to be mapped as page granularity, 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. >>>> >>>> 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. >>> >>> This patch still breaks the late-init capabilities that Kefeng pointed out. >>> >>> I think the only viable option is: >>> >>> 1. If KFENCE early init is requested on arm64, do what you're doing here. >>> >>> 2. If KFENCE is compiled in, but not enabled, do what was done >>> before, so it can be enabled late. >> >> I'm fine with above solution as well. The Disadvantage is if we want to >> dynamically disable kfence through kfence_sample_interval, it must be >> mapped into page granularity still. >> >>> >>> Am I missing an option? >>> >> >> Another option is what Kefeng firstly thought and I had proposed on >> comments of patchsetV3, actually I wanted to do in an separate patch: > > Please do it in the same patch (or patch series), otherwise we end up > with a regression. OK. > >> " >> So how about we raise another change, like you mentioned bootargs >> indicating to use late init of b33f778bba5e ("kfence: alloc kfence_pool > > Please avoid introducing another bootarg just for this. It will > confuse users and will cause serious annoyance (bad UX). OK, got it. > >> after system startup"). >> 1. in arm64_kfence_alloc_pool(): >> if (!kfence_sample_interval && !using_late_init) >> return 0; >> else >> allocate pool > > The whole point of late allocation was that the entire pool is _not_ > allocated until it's needed (during late init). So for space-conscious > users, this option is actually worse. > >> 2. also do the check in late allocation,like >> if (do_allocation_late && !using_late_init) >> BUG(); > > BUG() needs to be avoided. Just because a user used the system wrong, > should not cause it to crash (WARN instead)... but I'd really prefer > you avoid introducing another boot arg, because it'll lead to bad UX. > >> " >> The thought is to allocate pool early as well if we need to >> using_late_init. >> >> Kefeng, Marco, >> >> How's your idea? > > I recommend that you just make can_set_direct_map() conditional on > KFENCE being initialized early or not. With rodata protection most > arm64 kernels likely pay the page granular direct map cost anyway. And > for your special usecase where you want to optimize memory use, but > know that KFENCE is enabled, it'll result in the savings you desire. Thanks Marco, got your idea. Yeah.. rodata is another over-protection case. I will do the change following your suggestion for your review. > > Thanks, > -- Marco