-----Original Message----- > Hi, Kazu > Thank you for the comment. > > On Mon, May 31, 2021 at 9:42 AM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx <mailto:k-hagio-ab@xxxxxxx> > > wrote: > > > Hi Lianbo, > > > No, the patch fixes the above errors. Upstream kernel has changed the calculation formula in the > > freelist_ptr() as below(marked it with "^^^^"), which added the "swab()" operation, crash also > needs > > to follow up this change, otherwise crash will get the error of "invalid freepointer". > > > Before: > > crash> kmem -s > > CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME > > c0000000311a4200 152 0 0 0 64k fuse_request > > c0000000311a8700 800 0 0 0 64k fuse_inode > > c000000035df7600 528 0 0 0 64k xfs_dqtrx > > c000000035df6600 496 0 0 0 64k xfs_dquot > > kmem: xfs_buf: slab: c00c0000000b6500 invalid freepointer: 3808942d00004eb0 > > kmem: xfs_buf: slab: c00c00000116ba00 invalid freepointer: b83fe85a040027b0 > > ... > > Yes, you are right, and thanks for the info. > > I was confused because I could not reproduce the error message with a dozen > vmcores. > > > > > The above error messages are easily observed on ppc64le and s390 machines. > > > With some debugging, I think maybe the message itself does not occur on x86_64 > due to this issue, because get_freepointer() returns a value having 1 in bit 1 > on x86_64 and breaks the loop below. > > @@ -19361,6 +19361,7 @@ get_freepointer(struct meminfo *si, void *object) > return BADADDR; > } > > + fprintf(fp, "DEBUG: vaddr: %lx ptr: %lx\n", vaddr, freelist_ptr(si,nextfree,vaddr)); > return (freelist_ptr(si, nextfree, vaddr)); > } > > crash> kmem -s > CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME > ... > DEBUG: vaddr: ffff927b0501b5b8 ptr: b8b501057b92ec47 > DEBUG: vaddr: ffff927b05221bb8 ptr: b81b22057b92f8c7 > DEBUG: vaddr: ffff927b05218e38 ptr: 388e21057b92f647 > DEBUG: vaddr: ffff927b052269b8 ptr: b86922057b92f647 > ^bit1 = 1 > ffff927b08452200 360 802 840 40 8k xfs_buf > DEBUG: vaddr: ffff927b07991900 ptr: 1999077b92f1f7 > DEBUG: vaddr: ffff927b017ac130 ptr: 30c17a017b92f017 > DEBUG: vaddr: ffff927b0496d9c8 ptr: c8d996047b92fcc7 > DEBUG: vaddr: ffff927b01bce5e0 ptr: e0e5bc017b92f37f > ffff927b08452b00 200 50 480 24 4k xfs_bui_item > > for (q = freelist; q; q = get_freepointer(si, (void *)q)) { > if (q & PAGE_MAPPING_ANON) > break; <<-- break here > > > However, the issue affects the calculation of allocated/free objects > also on x86_64: > > -ffff927b08452200 360 802 840 40 8k xfs_buf > +ffff927b08452200 360 777 840 40 8k xfs_buf > ^^^ > > > > > Linux 5.7 and later kernels that contain kernel commit <1ad53d9fa3f6> > > > > ("slub: improve bit diffusion for freelist ptr obfuscation") changed > > > > the calculation formula in the freelist_ptr(), which added a swab() > > > > call to mix bits a little more. When kernel is built with the > > > > "CONFIG_SLAB_FREELIST_HARDENED=y",the "kmem -s" option fails with the > > > > following errors, if there is no such patch. > > So, could I change the latter part of the commit message to the following? > > > > > Yes, this also looks good. Thanks, applied. https://github.com/crash-utility/crash/commit/647a5c33e1c94054d7b63168cd6c12901591cb77 Kazu -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility
