linux-kernel - Re: [BUG?]Data key in /proc/allocinfo is a multiset

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] [day] [month] [year] [list]

Message-ID: <tmz2vkytqr27djdkcntshba2efdyjilxzx2cwmugy2fxapzvio@3olyd6gu333p>
Date: Fri, 9 May 2025 13:31:39 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: David Wang <00107082@....com>, akpm@...ux-foundation.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [BUG?]Data key in /proc/allocinfo is a multiset

On Fri, May 09, 2025 at 09:57:27AM -0700, Suren Baghdasaryan wrote:
> On Fri, May 9, 2025 at 9:36 AM David Wang <00107082@....com> wrote:
> >
> >
> > At 2025-05-09 23:56:32, "Suren Baghdasaryan" <surenb@...gle.com> wrote:
> > >On Thu, May 8, 2025 at 11:10 PM David Wang <00107082@....com> wrote:
> > >>
> > >> Just start a new thread for this[1].
> > >> There are duplications in /proc/allocinfo where same [file:line]
> > >> shows up several times:
> > >>
> > >> =======================
> > >>            0        0 ./include/crypto/kpp.h:185 func:kpp_request_alloc
> > >>            0        0 ./include/crypto/kpp.h:185 func:kpp_request_alloc
> > >> =======================
> > >>            0        0 ./include/net/tcp.h:2548 func:tcp_v4_save_options
> > >>            0        0 ./include/net/tcp.h:2548 func:tcp_v4_save_options
> > >> =======================
> > >>            0        0 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_alloc_pages_node
> > >>            0        0 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_alloc_pages_node
> > >>            0        0 drivers/iommu/amd/../iommu-pages.h:94 func:iommu_alloc_pages_node
> > >> =======================
> > >>            0        0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_alloc_pages_node
> > >>            0        0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_alloc_pages_node
> > >>            0        0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_alloc_pages_node
> > >>            0        0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_alloc_pages_node
> > >>            0        0 drivers/iommu/intel/../iommu-pages.h:94 func:iommu_alloc_pages_node
> > >
> > >Yep, that happens when an inlined function allocates memory. It ends
> > >up inlined in different locations. Usually that's done by allocation
> > >helper functions.
> > >To fix this we need to wrap these allocator helpers with alloc_hooks:
> > >
> > >-static inline void *iommu_alloc_pages_node(int nid, gfp_t gfp, int order)
> > >+static inline void *iommu_alloc_pages_node_noprof(int nid, gfp_t gfp,
> > >int order)
> > >{
> > >-        struct page *page = alloc_pages_node(nid, gfp | __GFP_ZERO,
> > >order);  struct skcipher_request *req;
> > >+        struct page *page = alloc_pages_node_noprof(nid, gfp |
> > >__GFP_ZERO, order);  struct skcipher_request *req;
> > >...
> > >}
> > >+#define iommu_alloc_pages_node(...)
> > >alloc_hooks(iommu_alloc_pages_node_noprof(__VA_ARGS__))
> > >
> > >See 2c321f3f70bc "mm: change inlined allocation helpers to account at
> > >the call site" for examples of how this was done before.
> > >Thanks,
> > >Suren.
> >
> > Thanks for clarifying this, seems like a never-ending work...... >_<|||
> 
> Like anything else in the kernel :)

Yeah, I generally end up doing these fixups here and there whenever I'm
staring at allocation profiling output - we should probably document the
process for that, and there's some nifty tricks you can do.

e.g. if you've got "container" data structure, like rhashtable, you
don't want allocations accounted to the rhashtable code itself - you
really want to know which rhashtable it was for.

So, you can create an alloc tag for the rhashtable_init() call (wrap it
in alloc_hooks), and then stash a pointer to that alloc tag in 'struct
rhashtable', and use that for all the rhashtable internal allocations.