On Mon, Dec 26, 2022 at 12:42 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx> 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
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility Contribution Guidelines: https://github.com/crash-utility/crash/wiki
