From: Suren Baghdasaryan <surenb@google.com>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: ranxiaokai627@163.com, vbabka@suse.cz, akpm@linux-foundation.org,
david@kernel.org, lorenzo.stoakes@oracle.com,
Liam.Howlett@oracle.com, rppt@kernel.org, mhocko@suse.com,
corbet@lwn.net, linux-mm@kvack.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, ran.xiaokai@zte.com.cn
Subject: Re: [PATCH] alloc_tag: remove sysctl prefix from mem_profiling boot parameter
Date: Sun, 11 Jan 2026 11:50:39 -0800 [thread overview]
Message-ID: <CAJuCfpGo4wYcMChX_xJJ04pHYKJ8vMPrkN9GFxXhW-1xQEmfiQ@mail.gmail.com> (raw)
In-Reply-To: <aWMLQkvushKidjQQ@moria.home.lan>
On Sat, Jan 10, 2026 at 6:34 PM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> 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?
>
> 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?
prev parent reply other threads:[~2026-01-11 19:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 6:24 ranxiaokai627
2026-01-11 2:12 ` Andrew Morton
2026-01-11 2:33 ` Kent Overstreet
2026-01-11 19:50 ` Suren Baghdasaryan [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=CAJuCfpGo4wYcMChX_xJJ04pHYKJ8vMPrkN9GFxXhW-1xQEmfiQ@mail.gmail.com \
--to=surenb@google.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=ran.xiaokai@zte.com.cn \
--cc=ranxiaokai627@163.com \
--cc=rppt@kernel.org \
--cc=vbabka@suse.cz \
/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