From: Hao Ge <hao.ge@linux.dev>
To: Hongfu Li <lihongfu@kylinos.cn>,
harry@kernel.org, willy@infradead.org, vbabka@kernel.org,
roman.gushchin@linux.dev, akpm@linux-foundation.org,
surenb@google.com, pasha.tatashin@soleen.com, hao.li@linux.dev
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] tools/cgroup/slabinfo: Fix use of slab.memcg_data
Date: Wed, 22 Apr 2026 17:30:30 +0800 [thread overview]
Message-ID: <30ed6e19-0d96-4d61-b991-6d0ab5198757@linux.dev> (raw)
In-Reply-To: <20260422073900.107311-1-lihongfu@kylinos.cn>
Hi Hongfu
On 2026/4/22 15:39, Hongfu Li wrote:
> After the introduce slabobj_ext to support slab object extensions, the
> memcg_slabinfo tool broke. An attempt to run it produces a trace like
> this:
> Traceback (most recent call last):
> File "/usr/local/bin/drgn", line 8, in <module>
> sys.exit(_main())
> ^^^^^^^
> File "/usr/local/lib64/python3.11/site-packages/drgn/cli.py", line 688, in _main
> runpy.run_path(
> File "<frozen runpy>", line 291, in run_path
> File "<frozen runpy>", line 98, in _run_module_code
> File "<frozen runpy>", line 88, in _run_code
> File "/root/memcg_slabinfo.py", line 225, in <module>
> main()
> File "/root/memcg_slabinfo.py", line 195, in main
> objcg_vec_raw = slab.memcg_data.value_()
> AttributeError: 'struct slab' has no member 'memcg_data'
>
> Fixes: 21c690a349ba ("mm: introduce slabobj_ext to support slab object extensions")
> Fixes: 5ba6bc27b1f9 ("slab: decouple pointer to barn from kmem_cache_node")
> Signed-off-by: Hongfu Li <lihongfu@kylinos.cn>
> ---
> v3:
> - Add a compatibility accessor for per-node cache state (per_node[nid].node vs node[nid])
> - Link to v2: https://lore.kernel.org/all/20260421055829.3930289-1-lihongfu@kylinos.cn/
> v2:
> - Skip slabs after masking when the base is zero (OBJEXTS_ALLOC_FAIL).
> - Walk slab->obj_exts using base + stride * i (same indexing as slab_obj_ext()).
> - Link to v1: https://lore.kernel.org/all/20260417020729.952897-1-lihongfu@kylinos.cn/
> ---
> tools/cgroup/memcg_slabinfo.py | 45 ++++++++++++++++++++++++++++------
> 1 file changed, 38 insertions(+), 7 deletions(-)
>
> diff --git a/tools/cgroup/memcg_slabinfo.py b/tools/cgroup/memcg_slabinfo.py
> index 6bf4bde77903..f49512831d6a 100644
> --- a/tools/cgroup/memcg_slabinfo.py
> +++ b/tools/cgroup/memcg_slabinfo.py
> @@ -33,6 +33,21 @@ def err(s):
> sys.exit(1)
>
>
> +def objexts_flags_mask():
> + try:
> + return int(prog.constant('__NR_OBJEXTS_FLAGS')) - 1
> + except:
> + return 0x7
> +
> +
> +def slab_obj_ext_stride(slab):
> + # Match slab_obj_ext() for both layouts: contiguous ext[] or ext-in-object
> + try:
> + return slab.stride.value_()
> + except AttributeError:
> + return prog.type('struct slabobj_ext').size
> +
> +
> def find_memcg_ids(css=prog['root_mem_cgroup'].css, prefix=''):
> if not list_empty(css.children.address_of_()):
> for css in list_for_each_entry('struct cgroup_subsys_state',
> @@ -68,6 +83,13 @@ def oo_objects(s):
> return s.oo.x & OO_MASK
>
>
> +def kmem_cache_get_node(s, nid):
> + try:
> + return s.per_node[nid].node
> + except AttributeError:
> + return s.node[nid]
> +
This gives me another idea.
So actually, we don't need to forcibly convert memcg_data to obj_exts,
right?
like this:
try:
raw = slab.memcg_data.value_()
new_layout = False
except AttributeError:
raw = slab.obj_exts.value_()
new_layout = True
and then take the new path based on new_layout.
But I'm not sure if we need to do this, as it would indeed make the
helper handle more and more cases.
Thanks
Best Regards
Hao
> +
> def count_partial(n, fn):
> nr_objs = 0
> for slab in list_for_each_entry('struct slab', n.partial.address_of_(),
> @@ -86,7 +108,9 @@ def slub_get_slabinfo(s, cfg):
> nr_free = 0
>
> for node in range(cfg['nr_nodes']):
> - n = s.node[node]
> + n = kmem_cache_get_node(s, node)
> + if not n.value_():
> + continue
> nr_slabs += n.nr_slabs.counter.value_()
> nr_objs += n.total_objects.counter.value_()
> nr_free += count_partial(n, count_free)
> @@ -192,23 +216,30 @@ def main():
> # look over all slab folios and look for objects belonging
> # to the given memory cgroup
> for slab in for_each_slab(prog):
> - objcg_vec_raw = slab.memcg_data.value_()
> - if objcg_vec_raw == 0:
> + objext_vec_raw = slab.obj_exts.value_()
> + if objext_vec_raw == 0:
> continue
> cache = slab.slab_cache
> if not cache:
> continue
> addr = cache.value_()
> caches[addr] = cache
> - # clear the lowest bit to get the true obj_cgroups
> - objcg_vec = Object(prog, 'struct obj_cgroup **',
> - value=objcg_vec_raw & ~1)
>
> if addr not in stats:
> stats[addr] = 0
>
> + # clear OBJEXTS_FLAGS_MASK bits to get the true slabobj_ext base.
> + # If OBJEXTS_ALLOC_FAIL, masked base is 0 - not tied to any cgroup.
> + mask = objexts_flags_mask()
> + objext_base = objext_vec_raw & ~mask
> + if objext_base == 0:
> + continue
> +
> + stride = slab_obj_ext_stride(slab)
> for i in range(oo_objects(cache)):
> - if objcg_vec[i].value_() in obj_cgroups:
> + objext = Object(prog, 'struct slabobj_ext *',
> + value=objext_base + stride * i)
> + if objext.objcg.value_() in obj_cgroups:
> stats[addr] += 1
>
> for addr in caches:
next prev parent reply other threads:[~2026-04-22 9:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 7:39 [PATCH v3] tools/cgroup/slabinfo: Fix use of slab.memcg_data Hongfu Li
2026-04-22 9:30 ` Hao Ge [this message]
2026-04-23 1:37 ` Hongfu Li
2026-04-27 1:28 ` Hongfu Li
2026-05-06 8:45 ` Hongfu Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30ed6e19-0d96-4d61-b991-6d0ab5198757@linux.dev \
--to=hao.ge@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=lihongfu@kylinos.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=roman.gushchin@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox