Re: [Crash-utility] [PATCH] Fix for "kmem <addr>" for kernels configured with CONFIG_SLUB and SLAB_RED_ZONE.

Dave Anderson <anderson(a)redhat.com&gt; writes: > That's kind of cluttered -- I was thinking of something like this: > > crash> kmem ffffea0004de2c00 > CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS > SSIZE > ffff88013a719900 ext4_inode_cache 2200 730 742 53 > 32k > SLAB MEMORY NODE TOTAL ALLOCATED FREE > RED_ZONE > ffffea0004de2c00 ffff8801378b0000 0 14 2 12 8 > FREE / [ALLOCATED] > ffff8801378b0000 (cpu 0 cache) > [ffff8801378b08b8] > > or better yet, this: > > crash> kmem ffffea0004de2c00 > CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS > SSIZE > ffff88013a719900 ext4_inode_cache 2200 730 742 53 > 32k > SLAB MEMORY NODE TOTAL ALLOCATED FREE > ffffea0004de2c00 ffff8801378b0000 0 14 2 12 > FREE / [ALLOCATED] SLAB_RED_ZONE: 8 > ffff8801378b0000 (cpu 0 cache) > [ffff8801378b08b8] I see what you say. However, my usual usage of kmem is to get the data address of object (I was thinking the most users are same usage). crash> kmem <pointer in stack> info for data address copy & paste <data address> crash> p *(struct inode *)<data address>

So I want to display <data address> itself (btw, cluttered is same with "cpu %d cache"). BTW, ->red_left_pad itself can get from CACHE's address, so if displaying <data address> is unacceptable, I would not have big interest to add ->red_left_pad itself. If this usage is only me, unfortunate though, I will apply this patch by myself. Thanks. -- OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp&gt;