linux-kernel - Re:[PATCH 1/1] alloc_tag: mark inaccurate allocation counters in /proc/allocinfo output

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: <20cafc1c.a658.199394de44e.Coremail.00107082@163.com>
Date: Thu, 11 Sep 2025 23:03:50 +0800 (CST)
From: "David Wang" <00107082@....com>
To: "Suren Baghdasaryan" <surenb@...gle.com>
Cc: akpm@...ux-foundation.org, kent.overstreet@...ux.dev, vbabka@...e.cz,
	hannes@...xchg.org, usamaarif642@...il.com, rientjes@...gle.com,
	roman.gushchin@...ux.dev, harry.yoo@...cle.com,
	shakeel.butt@...ux.dev, pasha.tatashin@...een.com,
	souravpanda@...gle.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re:[PATCH 1/1] alloc_tag: mark inaccurate allocation counters in
 /proc/allocinfo output


At 2025-09-10 07:49:42, "Suren Baghdasaryan" <surenb@...gle.com> wrote:
>While rare, memory allocation profiling can contain inaccurate counters
>if slab object extension vector allocation fails. That allocation might
>succeed later but prior to that, slab allocations that would have used
>that object extension vector will not be accounted for. To indicate
>incorrect counters, mark them with an asterisk in the /proc/allocinfo
>output.
>Bump up /proc/allocinfo version to reflect change in the file format.
>
>Example output with invalid counters:
>allocinfo - version: 2.0
>           0        0 arch/x86/kernel/kdebugfs.c:105 func:create_setup_data_nodes
>           0        0 arch/x86/kernel/alternative.c:2090 func:alternatives_smp_module_add
>          0*       0* arch/x86/kernel/alternative.c:127 func:__its_alloc
>           0        0 arch/x86/kernel/fpu/regset.c:160 func:xstateregs_set
>           0        0 arch/x86/kernel/fpu/xstate.c:1590 func:fpstate_realloc
>           0        0 arch/x86/kernel/cpu/aperfmperf.c:379 func:arch_enable_hybrid_capacity_scale
>           0        0 arch/x86/kernel/cpu/amd_cache_disable.c:258 func:init_amd_l3_attrs
>      49152*      48* arch/x86/kernel/cpu/mce/core.c:2709 func:mce_device_create
>       32768        1 arch/x86/kernel/cpu/mce/genpool.c:132 func:mce_gen_pool_create
>           0        0 arch/x86/kernel/cpu/mce/amd.c:1341 func:mce_threshold_create_device
>

Hi, 
The changes may  break some client tools, mine included.... 
I don't mind adjusting my tools, but still
Is it acceptable  to change 
      49152*      48* arch/x86/kernel/cpu/mce/core.c:2709 func:mce_device_create
to
      +49152      +48 arch/x86/kernel/cpu/mce/core.c:2709 func:mce_device_create*

The '+' sign make it still standout when view from a terminal, and client tools, not all of them though, might not need any changes. 
And when client want to filter out inaccurate data items, it could be done by checking the tailing '*" of func name.

(There would be some corner cases, for example, the '+' sign may not needed when the value reach a negative value if some underflow bug happened)


Thanks
David.


>Suggested-by: Johannes Weiner <hannes@...xchg.org>
>Signed-off-by: Suren Baghdasaryan <surenb@...gle.com>
>---