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: >> 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(a)mail.parknet.co.jp&gt;