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

[Dave Anderson]

----- Original Message -----
> 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>

Why not copy-and-paste the address from <pointer in stack>?  Or use "bt -FF"
to get the kmem cache type, and skip using "kmem" entirely?  ;-)

Dave


> 
> 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>
>