From: Zhenhua Huang <quic_zhenhuah@quicinc.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>,
<catalin.marinas@arm.com>, <will@kernel.org>, <glider@google.com>,
<elver@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>
Cc: <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>
Subject: Re: [PATCH v3] mm,kfence: decouple kfence from page granularity mapping judgement
Date: Fri, 10 Mar 2023 17:29:31 +0800 [thread overview]
Message-ID: <4dc71eb5-a5eb-d081-a73f-544b63e52537@quicinc.com> (raw)
In-Reply-To: <5251f2a0-95bf-3330-6524-ec5716cc3d29@huawei.com>
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 <mark.rutland@arm.com>
>> Signed-off-by: Zhenhua Huang <quic_zhenhuah@quicinc.com>
>> ---
>> 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 <linux/mm.h>
>> #include <linux/vmalloc.h>
>> #include <linux/set_memory.h>
>> +#include <linux/kfence.h>
>> #include <asm/barrier.h>
>> #include <asm/cputype.h>
>> @@ -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:)
prev parent reply other threads:[~2023-03-10 9:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 2:02 Zhenhua Huang
2023-03-10 2:56 ` Kefeng Wang
2023-03-10 9:29 ` Zhenhua Huang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4dc71eb5-a5eb-d081-a73f-544b63e52537@quicinc.com \
--to=quic_zhenhuah@quicinc.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=james.morse@arm.com \
--cc=jianyong.wu@arm.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=quic_guptap@quicinc.com \
--cc=quic_pkondeti@quicinc.com \
--cc=quic_tingweiz@quicinc.com \
--cc=robin.murphy@arm.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox