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