Dave Anderson <anderson@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
