[Crash-utility] Re: [PATCH] memory: Handle crash failure in linux-next caused by struct kmem_cache changes
Hi Mikhail,
Thanks for your fix on this!
On Tue, Jan 27, 2026 at 8:40 PM Mikhail Zaslonko <zaslonko(a)linux.ibm.com> wrote:
Since kernel commit cf338283652f ("slab: remove struct kmem_cache_cpu")
in linux-next we have no more 'cpu_slab' member in struct kmem_cache.
Pick 'cpu_sheaves' as an alternative kmem_cache member for kernel-next to
identify the SLUB case.
Without the patch, crash fails to start on kernel-next with the error
message:
crash: invalid structure member offset: kmem_cache_s_num
FILE: memory.c LINE: 9988 FUNCTION: kmem_cache_init()
This fix allows the crash to start with no errors. But kmap -s is no
longer working for kernel-next since kmem_cache_cpu array is completely
missing.
Signed-off-by: Mikhail Zaslonko <zaslonko(a)linux.ibm.com>
---
memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/memory.c b/memory.c
index cbc8d2f..3373fdb 100644
--- a/memory.c
+++ b/memory.c
@@ -672,6 +672,7 @@ vm_init(void)
} else if (!VALID_STRUCT(kmem_slab_s) &&
!VALID_STRUCT(slab_s) &&
!MEMBER_EXISTS("kmem_cache", "cpu_slab")
&&
+ !MEMBER_EXISTS("kmem_cache", "cpu_sheaves")
&&
(VALID_STRUCT(slab) || (vt->flags & SLAB_OVERLOAD_PAGE))) {
vt->flags |= PERCPU_KMALLOC_V2;
@@ -816,7 +817,7 @@ vm_init(void)
if (INVALID_MEMBER(page_first_page))
ANON_MEMBER_OFFSET_INIT(page_first_page, "page",
"first_page");
- } else if (MEMBER_EXISTS("kmem_cache", "cpu_slab")
&&
+ } else if ((MEMBER_EXISTS("kmem_cache", "cpu_slab") ||
MEMBER_EXISTS("kmem_cache", "cpu_sheaves")) &&
STRUCT_EXISTS("kmem_cache_node")) {
vt->flags |= KMALLOC_SLUB;
I tested your patch and find "kmem -s/-S" both not work:
crash> kmem -s
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
kmem: cannot determine location of kmem_cache.cpu_slab page
crash> kmem -S
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
kmem: cannot determine location of kmem_cache.cpu_slab page
And I add the following change upon your patch, to 1) let "kmem -s"
work and 2) "kmem -S" output error info.
@@ -5270,6 +5272,9 @@ cmd_kmem(void)
if (sflag || Sflag || rflag || !(vt->flags & KMEM_CACHE_INIT))
kmem_cache_init();
+ if (Sflag && MEMBER_EXISTS("kmem_cache",
"cpu_sheaves"))
+ error(FATAL, "-S not supported for this kernel\n");
+
while (args[optind]) {
if (hexadecimal(args[optind], 0)) {
value[spec_addr++] =
@@ -20401,7 +20406,6 @@ get_cpu_slab_ptr(struct meminfo *si, int cpu,
ulong *cpu_freelist)
default:
cpu_slab_ptr = 0;
- error(FATAL, "cannot determine location of
kmem_cache.cpu_slab page\n");
}
return cpu_slab_ptr;
And from my testing:
crash> kmem -s
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
ffff8b4e83d5fb00 2120 0 0 0 32k
nfs4_xattr_cache_cache
ffff8b4e83d5f200 216 0 0 0 4k nfs_direct_cache
ffff8b4e83d5fc00 736 28 42 2 16k nfs_commit_data
ffff8b4e83d5f900 936 56 68 4 16k nfs_write_data
...
To contrast with /proc/slabinfo:
nfs4_xattr_cache_cache 0 0 2128 15 8 : tunables 0
0 0 : slabdata 0 0 0
nfs_direct_cache 0 0 216 18 1 : tunables 0 0
0 : slabdata 0 0 0
nfs_commit_data 28 42 768 21 4 : tunables 0 0
0 : slabdata 2 2 0
nfs_write_data 56 68 960 17 4 : tunables 0 0
0 : slabdata 4 4 0
nfs_read_data 0 0 960 17 4 : tunables 0 0
0 : slabdata 0 0 0
The "kmem -s" output looks fine.
crash> kmem -S
kmem: -S not supported for this kernel
What do you think of this?
Thanks,
Tao Liu
--
2.52.0