Re: [Crash-utility] [PATCH] Fix for "kmem <addr>" for kernels configured with CONFIG_SLUB and SLAB_RED_ZONE.
Dave Anderson <anderson(a)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(a)mail.parknet.co.jp>