On Mon, Dec 26, 2022 at 12:42 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@nec.com> wrote:
On 2022/12/22 16:50, lijiang wrote:
> After applying the patch, I got another error based on the latest kernel
> commit 9d2f6060fe4c3b49d0cdc1dce1c99296f33379c8:
>
>   crash> kmem -S filp
> CACHE             OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE  NAME
> ffff9d80c030a100      232       1125      3936    123     8k  filp
> CPU 0 KMEM_CACHE_CPU:
>    ffff9d81e7a38470
> CPU 0 SLAB:
>    SLAB              MEMORY            NODE  TOTAL  ALLOCATED  FREE
>    fffff0f3841a7700  ffff9d80c69dc000     0     32         10    22
>    FREE / [ALLOCATED]
> kmem: filp: slab: fffff0f3841a7700 invalid freepointer: 4404c55079ecb7fe
> CPU 1 KMEM_CACHE_CPU:
>    ffff9d81e7a78470
> CPU 1 SLAB:
>    SLAB              MEMORY            NODE  TOTAL  ALLOCATED  FREE
>    fffff0f38446a600  ffff9d80d1a98000     0     32          0    32
>    FREE / [ALLOCATED]
> ...
>
> And this issue can not always be reproduced, I have tested it more than ten
> times, the above error can be observed on my side, maybe one or two times.
>
> But anyway, I'm curious if this is another issue. Could you please also
> double check it?

Thank you for testing.

I have not reproduced it with kdump, but did it with live system when
repeating this:

crash> kmem -S > /tmp/kmem-S
crash> kmem -S > /tmp/kmem-S
...
crash> kmem -S > /tmp/kmem-S
kmem: kmalloc-16: slab: ffffdb3bc440bcc0 invalid freepointer: d3ec64863a077e7c

As you say, it does not always happen, so it will be a timing issue or
corner case.  Maybe there was a change in managing freepointer list,
but so far I'm not sure what the cause is.


Theoretically, this issue can also be reproduced on kdump at a certain time point.
 
Anyway, I think it's not due to the offset change of slab.slab_list and
not the same issue.  Can we apply this and look into it later?


Yes, I agree that it might be another issue. Let's leave it there.
For the patch: Ack.
 
Thanks.
Lianbo

Thanks,
Kazu