linux-kernel - Re: [PATCH RFC] alloc_tag: add option to pick the first codetag along callchain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aVzorksJEyI0wlxh@moria.home.lan>
Date: Tue, 6 Jan 2026 05:54:36 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: David Wang <00107082@....com>
Cc: Suren Baghdasaryan <surenb@...gle.com>, akpm@...ux-foundation.org, 
	hannes@...xchg.org, pasha.tatashin@...een.com, souravpanda@...gle.com, 
	vbabka@...e.cz, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] alloc_tag: add option to pick the first codetag
 along callchain

On Tue, Jan 06, 2026 at 11:50:36AM +0800, David Wang wrote:
> At 2026-01-06 05:12:48, "Suren Baghdasaryan" <surenb@...gle.com> wrote:
> >On Mon, Dec 15, 2025 at 10:44 PM David Wang <00107082@....com> wrote:
> >>
> >> When tracking memory allocation for some specific function,
> >> picking the first codetag is more desired, because there
> >> is no need to track down all allocation sites in the call
> >> graph and change them to _noprof version, which is quite
> >> inflexible when the call graph is complex.
> >>
> >> For example, consider a simple graph:
> >>
> >> A ---> B ---> C ===> D
> >>        E ---> C
> >>
> >> ===> means a call with codetag
> >> ---> means a call without codetag
> >>
> >> To profiling memory allocation for A, the call graph needs
> >> to be changed to
> >> A ===> B ---> C ---> D
> >>        E ===> C
> >> Three call sites needs to be changed.
> >>
> >> But if pick the first codetag, only one change is needed.
> >> A ===> B ---> C ===> D
> >>        E ---> C
> >>
> >> The drawback is some accounting for C is splited to A,
> >> making the number not accurate for C. (But the overall
> >> accounting is still the same.)
> >>
> >> This is useful when debug memory problems, not meant for
> >> production usage though.
> >
> >Hi David,
> >Sorry for the delay. Do you have specific examples when allocation
> >needs to be accounted at the highest level
> Hi, 
> 
> I do not have a very convincing  practical example yet. :(
> I started to think about this in this thread[1], debugging possible memory leak in cephfs.
> If modules want to account its memory usage, they can plant codetags in their codepath
> without worrying about codetags deeper in the code chain.
> 
> And I noticed that some callsites' memory usage is incomplete, because its accounting
> is split by codetags deeper in the code chain 
> For example, on my system, I have
> 512        1 drivers/usb/core/hub.c:6080 [usbcore] func:usb_hub_init
> but if pick first codetag, I would have
> 20992        10 drivers/usb/core/hub.c:6080 [usbcore] func:usb_hub_init
> 
> One call chain  
>     usb_hub_init==>alloc_workqueue--->__alloc_workqueue -->alloc_node_nr_active==>kzalloc_node
> has two codetags, and its memory is not accounted to usb drivers.
> 
> If interested in module's memory usage,  picking the first codetag would be preferred, I guess.

Is an end user going to be able to do anything with such an option?

Your option just flattens the accounting - this results in incorrect
accounting, not just insufficiently fine grained - and incorrect in a
way that's harder to notice and find and fix.

How many times have you gone down the wrong rabbit hole because your
tools were subtly lying to you? This is something we really want to
avoid.

The fact that you have to be explicit about where the accounting happens
via _noprof is a feature, not a bug :)