Re: [PATCH] alloc_tag: remove sysctl prefix from mem_profiling boot parameter

[ranxiaokai627@163.com]

>On Fri, Jan 09, 2026 at 06:24:19AM +0000, ranxiaokai627@163.com wrote:
>> From: Ran Xiaokai <ran.xiaokai@zte.com.cn>
>> 
>> Boot parameters prefixed with "sysctl." are processed separately
>> during the final stage of system initialization via kernel_init()->
>> do_sysctl_args(). Since mem_profiling support should be parsed
>> in early boot stage, it is unsuitable for centralized handling
>> in do_sysctl_args().
>> Also, when CONFIG_MEM_ALLOC_PROFILING_DEBUG is enabled,
>> the sysctl.vm.mem_profiling entry is not writable and will cause
>> a warning. To prevent duplicate processing of sysctl.vm.mem_profiling,
>> rename the boot parameter to "mem_profiling".
>> 
>> Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn>
>
>How was this observed/detected?

Actually no kernel bug or funtional defect was observed through testing.
Via code reading, i found after commit [1],
boot parameters prefixed with sysctl is processed redundantly.

[1] https://lore.kernel.org/all/20200427180433.7029-3-vbabka@suse.cz/T/#u

>My reading of early_param() would seem to indicate that
>setup_early_mem_profiling() is getting called at the appropriate time -
>and then additionally a second time by do_sysctl_args(), which then
>becomes a noop.

In the handling of process_sysctl_arg(), it at least needs to call
kern_mount("proc"), file_open_root_mnt("/proc/sys/vm/xxx"), kernel_write(),
and filp_close() for processing.
I dont quite understand why it was optimized into a noop.

>So the only bug would seem to be that the sysctl is not writeable in
>debug mode? There's an easier fix for that one...

 - When debug mode is enabled, a warning is triggered because the file is not writable.
 - When debug mode is disabled, do_sysctl_args() cannot handle boot parameters
   like "1,compressed". It only accepts writes of 0 or 1.

As mem_profiling should be parsed in early boot, so this makes it
unsuitable for processing in do_sysctl_args(), which is why I have renamed the parameter.
But as Andrew mentioned, I did not consider the backward compatibility issues.