[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:
> 
> >> If SLAB_RED_ZONE is enabled, slub adds guard zone of sizeof(void *)
> >> onto head of slab page (red zone padding of left of object) on v4.6 or
> >> later.
> >> 
> >> Without this fix, like following SUPERBLK and [allocate addr] has
> >> difference.
> >> 
> >> crash> mount
> >>      MOUNT           SUPERBLK     TYPE   DEVNAME   DIRNAME
> >> ffff88013ae58040 ffff88013ac35698 rootfs rootfs    /
> >> [...]
> >> crash> kmem ffff88013ac35698
> >> CACHE            NAME                 OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE
> >> ffff88013ac05bc0 kmalloc-4096            4096        118       126     18  32k
> >>   SLAB              MEMORY            NODE  TOTAL  ALLOCATED  FREE
> >>   ffffea0004eb0c00  ffff88013ac30000     0      7          7     0
> >>   FREE / [ALLOCATED]
> >>   [ffff88013ac35690]
> >> [...]
> >
> > Hi Ogawa,
> >
> > When you enter "kmem ffff88013ac35698", I am presuming that it it
> > shows the [ALLOCATED] object at ffff88013ac35690 as shown above.  If
> > that's true, then in my opinion, it's doing the right thing.
> >
> > I understand that the kmalloc caller receives ffff88013ac35698, but
> > with respect to the slab subsystem itself, the actual address of the
> > slab object is ffff88013ac35690.  I worry about the potential
> > consequences of making such a wholesale change to the kmem command.
> 
> Hm, [addr] is not dumping slab address. It is dumping objects on slab
> actually. So I think rather confuses users. (BTW, slab address is
> represented as si->slab, and changes is against to vaddr)
> 
> Another example is,
> 
> crash> kmem ffffea0004d11600
> CACHE            NAME                 OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE
> ffff8801382271c0 ext4_inode_cache        2200        864       864     72  32k
>   SLAB              MEMORY            NODE  TOTAL  ALLOCATED  FREE
>   ffffea0004d11600  ffff880134458000     0     12         12     0
>   FREE / [ALLOCATED]
>   [ffff880134458000]
>   [ffff8801344589e8]
>   [ffff8801344593d0]
>   [ffff880134459db8]
>   [ffff88013445a7a0]
>   [ffff88013445b188]
>   [ffff88013445bb70]
>   [ffff88013445c558]
>   [ffff88013445cf40]
>   [ffff88013445d928]
>   [ffff88013445e310]
>   [ffff88013445ecf8]
> 
>       PAGE       PHYSICAL      MAPPING       INDEX CNT FLAGS
> ffffea0004d11600 134458000                0        0  1 8000000000004080 slab,head
> crash> struct ext4_inode_info.vfs_inode.i_op ffff880134458000
>   vfs_inode.i_op = 0xffffffffffffffff,
> crash> struct ext4_inode_info.vfs_inode.i_op ffff8801344589e8
>   vfs_inode.i_op = 0xffffffffffffffff,
> 
> 
> Specified slab address as argument of kmem command. It lists objects up.
> But as said, all objects are actually having 8 bytes diff. Correct
> result are the following.
> 
> crash> kmem ffffea0004d11600
> CACHE            NAME                 OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE
> ffff8801382271c0 ext4_inode_cache        2200        864       864     72  32k
>   SLAB              MEMORY            NODE  TOTAL  ALLOCATED  FREE
>   ffffea0004d11600  ffff880134458000     0     12         12     0
>   FREE / [ALLOCATED]
>   [ffff880134458008]
>   [ffff8801344589f0]
>   [ffff8801344593d8]
>   [ffff880134459dc0]
>   [ffff88013445a7a8]
>   [ffff88013445b190]
>   [ffff88013445bb78]
>   [ffff88013445c560]
>   [ffff88013445cf48]
>   [ffff88013445d930]
>   [ffff88013445e318]
>   [ffff88013445ed00]
> 
>       PAGE       PHYSICAL      MAPPING       INDEX CNT FLAGS
> ffffea0004d11600 134458000                0        0  1 8000000000004080 slab,head
> 
> crash> struct ext4_inode_info.vfs_inode.i_op ffff880134458008
>   vfs_inode.i_op = 0xffffffff81c2fe40 <ext4_fast_symlink_inode_operations>,
> crash> struct ext4_inode_info.vfs_inode.i_op ffff8801344589f0
>   vfs_inode.i_op = 0xffffffff81c2fe40 <ext4_fast_symlink_inode_operations>,
> 
> Thanks.
> --
> OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>
> 


Right, but the question is whether it makes more sense to display the
full slab object address containing the red-zone buffer or not.  When
debugging slab corruption for example, I would argue it's more relevant
to show the full object address.  For example, if you want to follow
that linked list from kmem_cache_cpu.freelist pointer, if I'm not mistaken
the next pointer in each object will be located in the first word of the 
object.  Anyway, that is more in line with the original intent of kmem -S
command, even in the case when slub debug is turned on.  

On the other hand, in your example above, you are presuming the address
shown should be what the kmalloc() or kmem_cache_alloc() caller receives, 
which I agree has merit.  But consider that you can enter any address
within an object, and get the same result.

I wonder whether there can be a compromise, such that in the case of slub
debug, there could be extra information in the output display that indicates
that the object contains a red zone buffer?

Dave