linux-kernel - Re: [PATCH v2 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: <CAJuCfpFQCgQLSrzfVjV+J4tkYbOx_W9v-kWmoo-rmh5hs9gEXA@mail.gmail.com>
Date: Mon, 15 Sep 2025 19:48:14 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: 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, 00107082@....com, 
	pyyjason@...il.com, pasha.tatashin@...een.com, souravpanda@...gle.com, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] alloc_tag: mark inaccurate allocation counters in
 /proc/allocinfo output

On Mon, Sep 15, 2025 at 5:11 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Mon, 15 Sep 2025 16:02:24 -0700 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, "accurate:no" marker is appended to the call site
> > line in the /proc/allocinfo output.
> > Bump up /proc/allocinfo version to reflect the change in the file format
> > and update documentation.
> >
> > 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 accurate:no
> >            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 accurate:no
> >        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
> >
> > ...
> >
> > --- a/Documentation/filesystems/proc.rst
> > +++ b/Documentation/filesystems/proc.rst
> > @@ -1009,6 +1009,10 @@ number, module (if originates from a loadable module) and the function calling
> >  the allocation. The number of bytes allocated and number of calls at each
> >  location are reported. The first line indicates the version of the file, the
> >  second line is the header listing fields in the file.
> > +If file version is 2.0 or higher then each line may contain additional
> > +<key>:<value> pairs representing extra information about the call site.
> > +For example if the counters are not accurate, the line will be appended with
> > +"accurate:no" pair.
>
> Perhaps we can tell people what accurate:no actually means.  It is a
> rather disturbing thing to see!  How worried should our users be about
> it?

Right. How about adding a section like this:

Supported markers in v2:
accurate:no
              Absolute values of the counters in this line are not
              accurate because of the failure to allocate storage required
              to track some of the allocations made at this location.
              Deltas in these counters are accurate, therefore counters
              can be used to track allocation size and count changes.


If this looks good, could you fold it into the existing patch or
should I respin?