[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJuCfpGo4wYcMChX_xJJ04pHYKJ8vMPrkN9GFxXhW-1xQEmfiQ@mail.gmail.com>
Date: Sun, 11 Jan 2026 11:50:39 -0800
From: Suren Baghdasaryan <surenb@...gle.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: ranxiaokai627@....com, vbabka@...e.cz, akpm@...ux-foundation.org,
david@...nel.org, lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com,
rppt@...nel.org, mhocko@...e.com, corbet@....net, linux-mm@...ck.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
ran.xiaokai@....com.cn
Subject: Re: [PATCH] alloc_tag: remove sysctl prefix from mem_profiling boot parameter
On Sat, Jan 10, 2026 at 6:34 PM Kent Overstreet
<kent.overstreet@...ux.dev> wrote:
>
> On Fri, Jan 09, 2026 at 06:24:19AM +0000, ranxiaokai627@....com wrote:
> > From: Ran Xiaokai <ran.xiaokai@....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@....com.cn>
>
> How was this observed/detected?
>
> 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.
>
> 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...
Sorry for the delay.
That's not a bug. We want this sysctrl to be read-only when the debug
option is enabled. Otherwise if user toggles mem_profiling sysctrl off
and then on again, all allocations that were made between these events
will be missing their tags and our debug mechanism will generate
warnings for each such occurrence when freeing these allocations.
I'll look closer into this warning. Maybe we can suppress it when the
read-only sysctrl is already set to the value being assigned to it?
Powered by blists - more mailing lists