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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <75285cc4.3c52.19b916d9490.Coremail.00107082@163.com>
Date: Tue, 6 Jan 2026 11:50:36 +0800 (CST)
From: "David Wang" <00107082@....com>
To: "Suren Baghdasaryan" <surenb@...gle.com>
Cc: kent.overstreet@...ux.dev, 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

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.


Thanks
David

https://lore.kernel.org/all/2a9ba88e.3aa6.19b0b73dd4e.Coremail.00107082@163.com/  [1]

>Our usual approach is that we account allocation at the lowest
>"allocator" level and if that allocator uses lowel level allocators it
>should use _noprof versions so that allocation is still done at the
>right level. I would like to keep that simple approach but if there
>are cases when that's not enough, I would like to know more about them
>before trying to address them.
>Thanks,
>Suren.
>
>>