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: <aV6BnhG9yjX10O27@moria.home.lan>
Date: Wed, 7 Jan 2026 11:13:25 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: David Wang <00107082@....com>
Cc: Suren Baghdasaryan <surenb@...gle.com>, 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

On Wed, Jan 07, 2026 at 02:16:24PM +0800, David Wang wrote:
> 
> At 2026-01-07 12:07:34, "Kent Overstreet" <kent.overstreet@...ux.dev> wrote:
> >I'm curious why you need to change __filemap_get_folio()? In filesystem
> >land we just lump that under "pagecache", but I guess you're doing more
> >interesting things with it in driver land?
> 
> Oh,  in [1],   there is a report about possible memory leak in cephfs, (The issue is still open, tracked in [2].), 
> large trunk of memory could not be released even after dropcache.
> memory allocation profiling shows those memory belongs to __filemap_get_folio,
> something like 
> >> ># sort -g /proc/allocinfo|tail|numfmt --to=iec
> >> >         12M     2987 mm/execmem.c:41 func:execmem_vmalloc 
> >> >         12M        3 kernel/dma/pool.c:96 func:atomic_pool_expand 
> >> >         13M      751 mm/slub.c:3061 func:alloc_slab_page 
> >> >         16M        8 mm/khugepaged.c:1069 func:alloc_charge_folio 
> >> >         18M     4355 mm/memory.c:1190 func:folio_prealloc 
> >> >         24M     6119 mm/memory.c:1192 func:folio_prealloc 
> >> >         58M    14784 mm/page_ext.c:271 func:alloc_page_ext 
> >> >         61M    15448 mm/readahead.c:189 func:ractl_alloc_folio 
> >> >         79M     6726 mm/slub.c:3059 func:alloc_slab_page 
> >> >         11G  2674488 mm/filemap.c:2012 func:__filemap_get_folio
> 
> After adding codetag to __filemap_get_folio, it shows
> 
> ># sort -g /proc/allocinfo|tail|numfmt --to=iec
> >         10M     2541 drivers/block/zram/zram_drv.c:1597 [zram]
> >func:zram_meta_alloc 12M     3001 mm/execmem.c:41 func:execmem_vmalloc 
> >         12M     3605 kernel/fork.c:311 func:alloc_thread_stack_node 
> >         16M      992 mm/slub.c:3061 func:alloc_slab_page 
> >         20M    35544 lib/xarray.c:378 func:xas_alloc 
> >         31M     7704 mm/memory.c:1192 func:folio_prealloc 
> >         69M    17562 mm/memory.c:1190 func:folio_prealloc 
> >        104M     8212 mm/slub.c:3059 func:alloc_slab_page 
> >        124M    30075 mm/readahead.c:189 func:ractl_alloc_folio 
> >        2.6G   661392 fs/netfs/buffered_read.c:635 [netfs] func:netfs_write_begin 
> >
> 
> Helpful or not, I am not sure. So far no bug has been spotted in the cephfs write path, yet.
> But at least, it provides more information and narrow down the scope of suspicious.
> 
> 
> https://lore.kernel.org/lkml/2a9ba88e.3aa6.19b0b73dd4e.Coremail.00107082@163.com/  [1]
> https://tracker.ceph.com/issues/74156   [2]

Well, my first thought when looking at that is that memory allocation
profiling is unlikely to be any more help there. Once you're dealing
with the page cache, if you're looking at a genuine leak it would pretty
much have to be a folio refcount leak, and the code that leaked the ref
could be anything that touched that folio - you're looking at a pretty
wide scope.

Unfortunately, we're not great at visibility and introspection in mm/,
and refcount bugs tend to be hard in general.

Better mm introspection would be helpful to say definitively that you're
looking at a refcount leak, but then once that's determined it's still
going to be pretty painful to track down.

The approach I took in bcachefs for refcount bugs was to write a small
library that in debug mode splits a refcount into sub-refcounts, and
then enumerate every single codepath that takes refs and gives them
distinct sub-refs - this means in debug mode we can instantly pinpoint
the function that's buggy (and even better, with the new CLASS() and
guard() stuff these sorts of bugs have been going away).

But grafting that onto folio refcounts would be a hell of a chore.

OTOH, converting code to CLASS() and guards is much more
straightforward - just a matter of writing little helpers if you need
them and then a bunch of mechanical conversions, and it's well worth it.

But, I'm reading through the Ceph code, and it has /less/ code involving
folio refcounts than I would expect.

Has anyone checked if the bug reproduces without zswap? I've definitely
seen a lot of bug reports involving that code.