Hi, Kazu
Thank you for the comment.
On Mon, May 31, 2021 at 9:42 AM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
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