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

[OGAWA Hirofumi]

Dave Anderson <anderson at redhat.com> 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 at mail.parknet.co.jp>