On 08/16/25 at 06:50am, Andrey Konovalov wrote: > On Thu, Aug 14, 2025 at 10:56 AM Baoquan He <b...@redhat.com> wrote: > > > > Ah, I got what you mean. We probably are saying different things. > > > > In order to record memory content of a corrupted kernel, we need reserve > > a memory region during bootup of a normal kernel (usually called 1st > > kernel) via kernel parameter crashkernel=nMB in advance. Then load > > kernel into the crashkernel memory region, that means the region is not > > usable for 1st kernel. When 1st kernel collapsed, we stop the 1st kernel > > cpu/irq and warmly switch to the loaded kernel in the crashkernel memory > > region (usually called kdump kernel). In kdump kernel, it boots up and > > enable necessary features to read out the 1st kernel's memory content, > > we usually use user space tool like makeudmpfile to filter out unwanted > > memory content. > > > > So this patchset intends to disable KASAN to decrease the crashkernel > > meomry value because crashkernel is not usable for 1st kernel. As for > > shadow memory of 1st kernel, we need recognize it and filter it away > > in makedumpfile. > > Ah, I see, thank you for the explanation! > > So kdump kernel runs with the amount of RAM specified by crashkernel=. > And KASAN's shadow memory increases RAM usage, which means > crashkernel= needs to be set to a higher value for KASAN kernels. Is > my understanding of the problem correct?
Yeah, you are quite right. When I tested it, on x86_64 and arm64, usually I set crashkernel=256M and it's sufficient. However, when KASAN is enabled and generic mode is taken, I need set crashkernel=768M to make vmcore dumping succeed. In kdump kernel, read_vmcore() uses ioremap to map the old memory of collapsed kernel for reading out, those vmalloc-ed areas are lazily freed and cause more shadow memory than what we usually think shadow memory only costs 1/8 of physical RAM.
