On 2022/12/26 15:47, lijiang wrote:
On Mon, Dec 26, 2022 at 12:42 PM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab(a)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, applied.
https://github.com/crash-utility/crash/commit/d83df2fb66cd77877d365fda32c...