[PATCH v8] mm,kfence: decouple kfence from page granularity mapping judgement

[Zhenhua Huang]

On 2023/3/15 16:52, Marco Elver wrote:
> On Wed, Mar 15, 2023 at 02:51PM +0800, Zhenhua Huang wrote:
> [...]
>>> Is it possible to free this early allocated memory later in
>>> mm_init()->kfence_alloc_pool()? if that is not possible, can we think of
>>> adding early param for kfence?
>>
>> If we freed that buffer, there may be no chance to get that page granularity
>> mapped buffer again.. as all these allocation/free are through normal buddy
>> allocator.
>>
>> At this stage, seems only additional early param can work.. Marco previously
>> wanted to reuse sample_interval but seems not doable now.
>>
>> Hi Marco,
>>
>> Sorry, Can we thought of the solution again? like
>> ARM64:
>> 1. intercepts early boot arg and gives early alloc memory to KFENCE
>> 2. KFENCE to disable dynamic switch
>> 3. disable page gran and save memory overhead
>> The purpose is in the case of w/o boot arg, it's just same as now.. arch
>> specific kfence buffer will not allocate. And w/ boot arg, we can get
>> expected saving.
> 
> You can get kfence.sample_interval with early_param(). mm/kfence/core.c
> should be left as is with a module param, so it can be set at runtime in
> /sys/modules/kfence/parameters/.
> 
> However you can add this to the #ifdef CONFIG_KFENCE in arm64 code
> you're adding:
> 
>    static bool kfence_early_init __initdata = !!CONFIG_KFENCE_SAMPLE_INTERVAL;
>    static int __init parse_kfence_early_init(char *p) {
>    	int val;
> 
>    	if (get_option(&p, &val))
>    		kfence_early_init = !!val;
>    	return 0;
>    }
>    early_param("kfence.sample_interval", parse_kfence_early_init);
> 
> Nothing is preventing us from parsing kfence.sample_interval twice
> during boot. At this stage you don't need the actual sample_interval,
> only if kfence.sample_interval was provided on the cmdline and is not 0.
> 
> That will avoid adding another new param.

I'm fine with above solution, Thanks Marco. Let me make the patch and 
share further.

Thanks,
Zhenhua

> 
> Thanks,
> -- Marco