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 97873C6FD19 for ; Mon, 13 Mar 2023 09:49:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0FEF26B0071; Mon, 13 Mar 2023 05:49:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AF326B0072; Mon, 13 Mar 2023 05:49:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB85B6B0074; Mon, 13 Mar 2023 05:49:49 -0400 (EDT) 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 DBE856B0071 for ; Mon, 13 Mar 2023 05:49:49 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A7F79C07EF for ; Mon, 13 Mar 2023 09:49:49 +0000 (UTC) X-FDA: 80563403298.13.0D0E5C4 Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) by imf30.hostedemail.com (Postfix) with ESMTP id 0417C80012 for ; Mon, 13 Mar 2023 09:49:47 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=sCcGOy6q; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of elver@google.com designates 209.85.166.180 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678700988; 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=AECH0PFKZyEMTjHkgiwjGaTvNaBtToW0575sLXnAvi4=; b=an02uRtJCQOCpHfaEtK3lgex34nORdr+YCknB0cvyUXk3AqFyLMcyOXES6Uh7s/bzlbdTt kob+1Qjk/K4XXvHhrciohZzgdmgHF9DBMcOyNx7KHX/cFICtqP+ThGOCAxSCITkShZO04l JCzKqN+tOfRwHjfSG1CPv8pOPJ2mW4A= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=sCcGOy6q; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of elver@google.com designates 209.85.166.180 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678700988; a=rsa-sha256; cv=none; b=V/atBpyaWLPeNt+Wtvb1qh1qxK3EYPvVaFu7H/KVRIxH9Z7pz4M1iMKrZVpWft5gHpWwAd 5VLoagyg1C5AoA+pMYAaCYt6Dq73977BNx7a1I6DjcPgDp+aRTlMDpGyNOEJNcbwI7e3Lh 00at+HSjywZeVqBGzRI+OurB7bptrGY= Received: by mail-il1-f180.google.com with SMTP id bp11so1258316ilb.3 for ; Mon, 13 Mar 2023 02:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1678700987; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AECH0PFKZyEMTjHkgiwjGaTvNaBtToW0575sLXnAvi4=; b=sCcGOy6qSjsk4kLWgrHL5Gw94QSO6w4tZZoyjy394+TDaqY8Sw62ZiHmRzfdzFb6EU gypttQnH2dVdJ9BSNANcVJDZ55JSM3bc4FSecFyq6RgA8iZC1DgFdLffpKA3JHm9xZeN FEG/eUoW/7GF7nekGMM5+tuqrECVodo0uXyNO2kc1OGnIrTvsCs1bmUg83tXHMGT85Go SYfpBt6q3X4XLdoUUPUqkm0YEdwmjLWBeUO4vuRfPRB3FqnQ1aQfVZLtPTK2AmscY0y2 KoTRhl0T6HJT/SznkjW0elI0h7wTRuWClsU/ckaO4Ap3DcrpRIeFD7IL0OwlJ42cBNFf YBiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678700987; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AECH0PFKZyEMTjHkgiwjGaTvNaBtToW0575sLXnAvi4=; b=vKZehjiLUwrd0rDO/kzU3Fz6Ntavah6g/kt73VnTgweIhXnJthgfd4dhWKIj0aj2AB 5XOi1ngIOLLruUB1bMedikM5h7DRzYNMxLJfiOcHChUYS2eRrGWTvEClssmOlVphitij A755ooeJsXCrfMtc4wjOl8OBeGaAs9pMpzl+fWJUeOJQo0qUlBZnCPoC9wCf6Yg2Jqgi Qz4IvJY3m3S079ZxihBhaGk+Xo7t8iO+ewH1JD6dTViV09RPFJwPoHz8pQDyVJk665VK O+cdZ+gkBcvSzrUj6Sw/OGUBHXq1sYnk6hAKB6X7ZT/P+XUEhiLIctSrGVvPYfVD6U3o /UIg== X-Gm-Message-State: AO0yUKU5FQZK+iPZ8YlUUc5Tbo9Y/z2+Prqj0Hk6jU83/NKglyD6ulOx FymjGST9YDIs3cmbvJCAZ4z29oBsl6WCsm7vYeK0Rg== X-Google-Smtp-Source: AK7set9624wWwKo8QhdivcRAQl/qGPb3VIEhYbhGlR+BnAoyqi6Xv5Fd6ld9903QpffC0+UTFa62C+B4viGDp5r/vIA= X-Received: by 2002:a92:cccd:0:b0:323:45f:681 with SMTP id u13-20020a92cccd000000b00323045f0681mr1572016ilq.4.1678700986962; Mon, 13 Mar 2023 02:49:46 -0700 (PDT) MIME-Version: 1.0 References: <1678683825-11866-1-git-send-email-quic_zhenhuah@quicinc.com> <8b44b20d-675c-25d0-6ddb-9b02da1c72d2@quicinc.com> In-Reply-To: <8b44b20d-675c-25d0-6ddb-9b02da1c72d2@quicinc.com> From: Marco Elver Date: Mon, 13 Mar 2023 10:49:04 +0100 Message-ID: Subject: Re: [PATCH v5] mm,kfence: decouple kfence from page granularity mapping judgement To: Zhenhua Huang Cc: catalin.marinas@arm.com, will@kernel.org, glider@google.com, dvyukov@google.com, akpm@linux-foundation.org, robin.murphy@arm.com, mark.rutland@arm.com, jianyong.wu@arm.com, james.morse@arm.com, wangkefeng.wang@huawei.com, linux-arm-kernel@lists.infradead.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, quic_pkondeti@quicinc.com, quic_guptap@quicinc.com, quic_tingweiz@quicinc.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 0417C80012 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: xcu8118e1mfcgya97z7px9ceqnbhr9fe X-HE-Tag: 1678700987-412685 X-HE-Meta: U2FsdGVkX1+hwYD8wZQUT2ScNZ1uaSaWPD4T/+nK17e65emkIYgXkP0EW+50C3+z9klQlBb9PlsUqLazRFEbwAUSLQFjKeXYYSFV77R0u2UwnMgCSe40X6vIRHoLG98QPmT/+q9I1+GUOlhSlBdSYnFL6FGOqYX477lNaIgfyUgBK4K0couJmn2CxyRVyRC6J1OtTU6Zg9cLlbQOyZimUyYzzyUcOVokSCebmJC9kArYJZA+pDXJT3QHfjtAxKP2lES/lJpj0k93YXLoO68qhuWSj776q4wcGp3HJP/kzVqPe1JG7JkFM+j8mIzsGzAIPK3HAa+NG3TKhBP+EWoUpHinA4cKpiYnaREw0WQjpdwR5qSaw+Vp0SnOOTSDhO+C4EvL7+uOXe7sptqYj+2CfUeIAqHXUiwoyM9p/2caMzGg8yEhRpk+SN0DgKHiLvj2UJtR73PrjfnFNbPoSx0r/aXQrii950gpoXrkfznbAG+rExCvZ5RwHOIXeD5ViOYcXxRscnEEIEbNcVGBjjdnnfzsurPRwUPlBNLYqgzyBZSprpxlXanS/cA/nQXqjE60Z3djdqXuUvxBT79TL6bPF+dR9v2PPdDHaxhCsxoPYpd3uf46ig9vOw9m70k3ZJ6lj9w9EZu4/jynfUjmLSwv6iHL45RMB4mtlgT/w4di/KAVs3sGyu1ORSWrLjcrQD+6l+gRU5x/Ut8Sexm6OhpwnlyHwDFsyJRYM6Rj3LSzUeO5LIYCdau7GAQYS7yh4OEjQDUeEGeUQ5Sc2p8pROqpgcimoT4tGDGP7NlmMQKNdaGXOXEJTDJ8LJ57gBq5UU3gEifxQ2P7zkWC96YVdq9SG2ILkn+vDv4NESOtr4H79xx+6XrwL75dfqJz7ei0zmbJfy10YIOWkUH9KGkkq+Pkml1MkUQK7Uhrwty03xk07Sg/GU+5ihph7hsqWQs3rgy03qb1o49966wsfUE7zwx 0Aun2NGP HiwyhRWHJRztPkTnWhECtROn8ZN2vje33SiYD5+KRiCFBNlVz0WS0x+AdITimJXGOKEMkeMQrImkI1ox8gUI7HpbxT4wwPB/J1FSNj+P+owb9hwb0lm388a+ScpF3soGfvq2bW63E1LE5x8RPCPmx33xohgdeaekRSH2ZXXnxo3z/FRa3Kk9y4DbpWqdNohXnkajSDRahRydGgYM2GSkHh174HG1joS8568Aky3bx8pijJBR6dniaLJEvAZFxUtCran77op59lqAXx1piostXSo0qoa5mJalFKBEqY91ueUPDq6A1tfcG5m5ThA== 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 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. > " > 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). > 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