[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aC2rNv49pzy1Wh3D@MiWiFi-R3L-srv>
Date: Wed, 21 May 2025 18:30:14 +0800
From: Baoquan He <bhe@...hat.com>
To: Zhongkun He <hezhongkun.hzk@...edance.com>
Cc: Alexander Graf <graf@...zon.com>, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Pasha Tatashin <pasha.tatashin@...een.com>,
nh-open-source@...zon.com
Subject: Re: [External] [PATCH v3] kexec: Enable CMA based contiguous
allocation
On 05/21/25 at 03:47pm, Zhongkun He wrote:
> On Wed, May 14, 2025 at 2:40 AM Alexander Graf <graf@...zon.com> wrote:
......
> > /**
> > * kexec_locate_mem_hole - find free memory for the purgatory or the next kernel
> > * @kbuf: Parameters for the memory search.
> > @@ -648,6 +684,13 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> > if (kbuf->mem != KEXEC_BUF_MEM_UNKNOWN)
> > return 0;
> >
> > + /*
> > + * Try to find a free physically contiguous block of memory first. With that, we
> > + * can avoid any copying at kexec time.
> > + */
> > + if (!kexec_alloc_contig(kbuf))
> > + return 0;
>
> IIUC, The kexec_locate_mem_hole() function is also used in
> the KEXEC_TYPE_CRASH kimage, but kexec_alloc_contig() does not skip it.
> This can cause kdump to fail and lead to CMA memory leakage.
That is true and good catch, and fix is needed to skip cma alloc for
kdump.
>
> So I ran some tests, as listed below:
> The CMA memory decreases with each execution of the kdump-config
> reload operation.
>
> /home/hezhongkun.hzk# kdump-config reload
> unloaded kdump kernel.
> Creating symlink /var/lib/kdump/vmlinuz.
> Creating symlink /var/lib/kdump/initrd.img.
> kexec_file_load failed: Cannot assign requested address
> failed to load kdump kernel ... failed!
>
> [ 1387.536346] kexec_file: allocated 1817 DMA pages at 0x11b16e
> [ 1399.147677] kexec_file: allocated 113 DMA pages at 0x119087
> [ 1399.148915] kexec_file: allocated 5 DMA pages at 0x1140f8
> [ 1399.150266] kexec_file: allocated 2 DMA pages at 0x1118fd
> [ 1399.151474] kexec_file: allocated 8302 DMA pages at 0x11b900
>
> /home/hezhongkun.hzk# cat /proc/meminfo | grep Cma
> CmaTotal: 1048576 kB
> CmaFree: 679972 kB
> /home/hezhongkun.hzk# cat /proc/meminfo | grep Cma
> CmaTotal: 1048576 kB
> CmaFree: 639016 kB
> /home/hezhongkun.hzk# cat /proc/meminfo | grep Cma
> CmaTotal: 1048576 kB
> CmaFree: 557104 kB
>
> cat /proc/meminfo | grep Cma
> CmaTotal: 1048576 kB
> CmaFree: 557104 kB
>
> > +
> > if (!IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK))
> > ret = kexec_walk_resources(kbuf, locate_mem_hole_callback);
> > else
> > @@ -693,6 +736,7 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
> > /* Ensure minimum alignment needed for segments. */
> > kbuf->memsz = ALIGN(kbuf->memsz, PAGE_SIZE);
> > kbuf->buf_align = max(kbuf->buf_align, PAGE_SIZE);
> > + kbuf->cma = NULL;
> >
> > /* Walk the RAM ranges and allocate a suitable range for the buffer */
> > ret = arch_kexec_locate_mem_hole(kbuf);
> > @@ -705,6 +749,7 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
> > ksegment->bufsz = kbuf->bufsz;
> > ksegment->mem = kbuf->mem;
> > ksegment->memsz = kbuf->memsz;
> > + kbuf->image->segment_cma[kbuf->image->nr_segments] = kbuf->cma;
> > kbuf->image->nr_segments++;
> > return 0;
> > }
> > diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
> > index d35d9792402d..29e6cebe0c43 100644
> > --- a/kernel/kexec_internal.h
> > +++ b/kernel/kexec_internal.h
> > @@ -10,7 +10,7 @@ struct kimage *do_kimage_alloc_init(void);
> > int sanity_check_segment_list(struct kimage *image);
> > void kimage_free_page_list(struct list_head *list);
> > void kimage_free(struct kimage *image);
> > -int kimage_load_segment(struct kimage *image, struct kexec_segment *segment);
> > +int kimage_load_segment(struct kimage *image, int idx);
> > void kimage_terminate(struct kimage *image);
> > int kimage_is_destination_range(struct kimage *image,
> > unsigned long start, unsigned long end);
> > --
> > 2.34.1
> >
> >
> >
> >
> > Amazon Web Services Development Center Germany GmbH
> > Tamara-Danz-Str. 13
> > 10243 Berlin
> > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> > Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> > Sitz: Berlin
> > Ust-ID: DE 365 538 597
> >
> >
>
Powered by blists - more mailing lists