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

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