linux-kernel - Re: [PATCH v6 00/37] Memory allocation profiling

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]

Date: Thu, 21 Mar 2024 13:41:57 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: kent.overstreet@...ux.dev, mhocko@...e.com, vbabka@...e.cz,
 hannes@...xchg.org, roman.gushchin@...ux.dev, mgorman@...e.de,
 dave@...olabs.net, willy@...radead.org, liam.howlett@...cle.com,
 penguin-kernel@...ove.sakura.ne.jp, corbet@....net, void@...ifault.com,
 peterz@...radead.org, juri.lelli@...hat.com, catalin.marinas@....com,
 will@...nel.org, arnd@...db.de, tglx@...utronix.de, mingo@...hat.com,
 dave.hansen@...ux.intel.com, x86@...nel.org, peterx@...hat.com,
 david@...hat.com, axboe@...nel.dk, mcgrof@...nel.org, masahiroy@...nel.org,
 nathan@...nel.org, dennis@...nel.org, jhubbard@...dia.com, tj@...nel.org,
 muchun.song@...ux.dev, rppt@...nel.org, paulmck@...nel.org,
 pasha.tatashin@...een.com, yosryahmed@...gle.com, yuzhao@...gle.com,
 dhowells@...hat.com, hughd@...gle.com, andreyknvl@...il.com,
 keescook@...omium.org, ndesaulniers@...gle.com, vvvvvv@...gle.com,
 gregkh@...uxfoundation.org, ebiggers@...gle.com, ytcoode@...il.com,
 vincent.guittot@...aro.org, dietmar.eggemann@....com, rostedt@...dmis.org,
 bsegall@...gle.com, bristot@...hat.com, vschneid@...hat.com, cl@...ux.com,
 penberg@...nel.org, iamjoonsoo.kim@....com, 42.hyeyoo@...il.com,
 glider@...gle.com, elver@...gle.com, dvyukov@...gle.com,
 songmuchun@...edance.com, jbaron@...mai.com, aliceryhl@...gle.com,
 rientjes@...gle.com, minchan@...gle.com, kaleshsingh@...gle.com,
 kernel-team@...roid.com, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
 linux-arch@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-mm@...ck.org, linux-modules@...r.kernel.org,
 kasan-dev@...glegroups.com, cgroups@...r.kernel.org
Subject: Re: [PATCH v6 00/37] Memory allocation profiling

On Thu, 21 Mar 2024 09:36:22 -0700 Suren Baghdasaryan <surenb@...gle.com> wrote:

> Low overhead [1] per-callsite memory allocation profiling. Not just for
> debug kernels, overhead low enough to be deployed in production.
> 
> Example output:
>   root@...ia-kvm:~# sort -rn /proc/allocinfo
>    127664128    31168 mm/page_ext.c:270 func:alloc_page_ext
>     56373248     4737 mm/slub.c:2259 func:alloc_slab_page
>     14880768     3633 mm/readahead.c:247 func:page_cache_ra_unbounded
>     14417920     3520 mm/mm_init.c:2530 func:alloc_large_system_hash
>     13377536      234 block/blk-mq.c:3421 func:blk_mq_alloc_rqs
>     11718656     2861 mm/filemap.c:1919 func:__filemap_get_folio
>      9192960     2800 kernel/fork.c:307 func:alloc_thread_stack_node
>      4206592        4 net/netfilter/nf_conntrack_core.c:2567 func:nf_ct_alloc_hashtable
>      4136960     1010 drivers/staging/ctagmod/ctagmod.c:20 [ctagmod] func:ctagmod_start
>      3940352      962 mm/memory.c:4214 func:alloc_anon_folio
>      2894464    22613 fs/kernfs/dir.c:615 func:__kernfs_new_node

Did you consider adding a knob to permit all the data to be wiped out? 
So people can zap everything, run the chosen workload then go see what
happened?

Of course, this can be done in userspace by taking a snapshot before
and after, then crunching on the two....