Hi, Kazu
Thank you for the comment.
On Mon, May 31, 2021 at 9:42 AM HAGIO KAZUHITO(萩尾 一仁) <[email protected]>
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.
Lianbo
> When kernel is configured with the "CONFIG_SLAB_FREELIST_HARDENED=y",
> Without the patch, the "kmem -s|-S" option displays wrong statistics and
> state whether the slab objects are in use or free and can print the
> following errors.
>
> Thanks,
> Kazu
>
>
--
Crash-utility mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/crash-utility
