[PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Pingfan Liu]

The kexec segment index will be required to extract the corresponding
information for that segment in kimage_map_segment(). Additionally,
kexec_segment already holds the kexec relocation destination address and
size. Therefore, the prototype of kimage_map_segment() can be changed.

Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Roberto Sassu <roberto.sassu@huawei.com>
Cc: Alexander Graf <graf@amazon.com>
Cc: Steven Chen <chenste@linux.microsoft.com>
Cc: <stable@vger.kernel.org>
To: kexec@lists.infradead.org
To: linux-integrity@vger.kernel.org
---
 include/linux/kexec.h              | 4 ++--
 kernel/kexec_core.c                | 9 ++++++---
 security/integrity/ima/ima_kexec.c | 4 +---
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index ff7e231b0485..8a22bc9b8c6c 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print;
 #define kexec_dprintk(fmt, arg...) \
         do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
 
-extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
+extern void *kimage_map_segment(struct kimage *image, int idx);
 extern void kimage_unmap_segment(void *buffer);
 #else /* !CONFIG_KEXEC_CORE */
 struct pt_regs;
@@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
 static inline void crash_kexec(struct pt_regs *regs) { }
 static inline int kexec_should_crash(struct task_struct *p) { return 0; }
 static inline int kexec_crash_loaded(void) { return 0; }
-static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
+static inline void *kimage_map_segment(struct kimage *image, int idx)
 { return NULL; }
 static inline void kimage_unmap_segment(void *buffer) { }
 #define kexec_in_progress false
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index fa00b239c5d9..9a1966207041 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *image, int idx)
 	return result;
 }
 
-void *kimage_map_segment(struct kimage *image,
-			 unsigned long addr, unsigned long size)
+void *kimage_map_segment(struct kimage *image, int idx)
 {
+	unsigned long addr, size, eaddr;
 	unsigned long src_page_addr, dest_page_addr = 0;
-	unsigned long eaddr = addr + size;
 	kimage_entry_t *ptr, entry;
 	struct page **src_pages;
 	unsigned int npages;
 	void *vaddr = NULL;
 	int i;
 
+	addr = image->segment[idx].mem;
+	size = image->segment[idx].memsz;
+	eaddr = addr + size;
+
 	/*
 	 * Collect the source pages and map them in a contiguous VA range.
 	 */
diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
index 7362f68f2d8b..5beb69edd12f 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image)
 	if (!image->ima_buffer_addr)
 		return;
 
-	ima_kexec_buffer = kimage_map_segment(image,
-					      image->ima_buffer_addr,
-					      image->ima_buffer_size);
+	ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index);
 	if (!ima_kexec_buffer) {
 		pr_err("Could not map measurements buffer.\n");
 		return;
-- 
2.49.0

[PATCHv2 2/2] kernel/kexec: Fix IMA when allocation happens in CMA area

[Pingfan Liu]

When I tested kexec with the latest kernel, I ran into the following warning:

[   40.712410] ------------[ cut here ]------------
[   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198
[...]
[   40.816047] Call trace:
[   40.818498]  kimage_map_segment+0x144/0x198 (P)
[   40.823221]  ima_kexec_post_load+0x58/0xc0
[   40.827246]  __do_sys_kexec_file_load+0x29c/0x368
[...]
[   40.855423] ---[ end trace 0000000000000000 ]---

This is caused by the fact that kexec allocates the destination directly
in the CMA area. In that case, the CMA kernel address should be exported
directly to the IMA component, instead of using the vmalloc'd address.

Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Alexander Graf <graf@amazon.com>
Cc: Steven Chen <chenste@linux.microsoft.com>
Cc: linux-integrity@vger.kernel.org
Cc: <stable@vger.kernel.org>
To: kexec@lists.infradead.org
---
v1 -> v2:
return page_address(page) instead of *page

 kernel/kexec_core.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 9a1966207041..332204204e53 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -967,6 +967,7 @@ void *kimage_map_segment(struct kimage *image, int idx)
 	kimage_entry_t *ptr, entry;
 	struct page **src_pages;
 	unsigned int npages;
+	struct page *cma;
 	void *vaddr = NULL;
 	int i;
 
@@ -974,6 +975,9 @@ void *kimage_map_segment(struct kimage *image, int idx)
 	size = image->segment[idx].memsz;
 	eaddr = addr + size;
 
+	cma = image->segment_cma[idx];
+	if (cma)
+		return page_address(cma);
 	/*
 	 * Collect the source pages and map them in a contiguous VA range.
 	 */
@@ -1014,7 +1018,8 @@ void *kimage_map_segment(struct kimage *image, int idx)
 
 void kimage_unmap_segment(void *segment_buffer)
 {
-	vunmap(segment_buffer);
+	if (is_vmalloc_addr(segment_buffer))
+		vunmap(segment_buffer);
 }
 
 struct kexec_load_limit {
-- 
2.49.0

Re: [PATCHv2 2/2] kernel/kexec: Fix IMA when allocation happens in CMA area

[Baoquan He]

On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> When I tested kexec with the latest kernel, I ran into the following warning:
> 
> [   40.712410] ------------[ cut here ]------------
> [   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198
> [...]
> [   40.816047] Call trace:
> [   40.818498]  kimage_map_segment+0x144/0x198 (P)
> [   40.823221]  ima_kexec_post_load+0x58/0xc0
> [   40.827246]  __do_sys_kexec_file_load+0x29c/0x368
> [...]
> [   40.855423] ---[ end trace 0000000000000000 ]---
> 
> This is caused by the fact that kexec allocates the destination directly
> in the CMA area. In that case, the CMA kernel address should be exported
> directly to the IMA component, instead of using the vmalloc'd address.

Well, you didn't update the log accordingly.

Do you know why cma area can't be mapped into vmalloc?

> 
> Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> Signed-off-by: Pingfan Liu <piliu@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Alexander Graf <graf@amazon.com>
> Cc: Steven Chen <chenste@linux.microsoft.com>
> Cc: linux-integrity@vger.kernel.org
> Cc: <stable@vger.kernel.org>
> To: kexec@lists.infradead.org
> ---
> v1 -> v2:
> return page_address(page) instead of *page
> 
>  kernel/kexec_core.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 9a1966207041..332204204e53 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -967,6 +967,7 @@ void *kimage_map_segment(struct kimage *image, int idx)
>  	kimage_entry_t *ptr, entry;
>  	struct page **src_pages;
>  	unsigned int npages;
> +	struct page *cma;
>  	void *vaddr = NULL;
>  	int i;
>  
> @@ -974,6 +975,9 @@ void *kimage_map_segment(struct kimage *image, int idx)
>  	size = image->segment[idx].memsz;
>  	eaddr = addr + size;
>  
> +	cma = image->segment_cma[idx];
> +	if (cma)
> +		return page_address(cma);
>  	/*
>  	 * Collect the source pages and map them in a contiguous VA range.
>  	 */
> @@ -1014,7 +1018,8 @@ void *kimage_map_segment(struct kimage *image, int idx)
>  
>  void kimage_unmap_segment(void *segment_buffer)
>  {
> -	vunmap(segment_buffer);
> +	if (is_vmalloc_addr(segment_buffer))
> +		vunmap(segment_buffer);
>  }
>  
>  struct kexec_load_limit {
> -- 
> 2.49.0
> 

Re: [PATCHv2 2/2] kernel/kexec: Fix IMA when allocation happens in CMA area

[Pingfan Liu]

On Thu, Nov 6, 2025 at 4:01 PM Baoquan He <bhe@redhat.com> wrote:
>
> On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > When I tested kexec with the latest kernel, I ran into the following warning:
> >
> > [   40.712410] ------------[ cut here ]------------
> > [   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198
> > [...]
> > [   40.816047] Call trace:
> > [   40.818498]  kimage_map_segment+0x144/0x198 (P)
> > [   40.823221]  ima_kexec_post_load+0x58/0xc0
> > [   40.827246]  __do_sys_kexec_file_load+0x29c/0x368
> > [...]
> > [   40.855423] ---[ end trace 0000000000000000 ]---
> >
> > This is caused by the fact that kexec allocates the destination directly
> > in the CMA area. In that case, the CMA kernel address should be exported
> > directly to the IMA component, instead of using the vmalloc'd address.
>
> Well, you didn't update the log accordingly.
>

I am not sure what you mean. Do you mean the earlier content which I
replied to you?

> Do you know why cma area can't be mapped into vmalloc?
>
Should not the kernel direct mapping be used?

Thanks,

Pingfan
> >
> > Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> > Signed-off-by: Pingfan Liu <piliu@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Baoquan He <bhe@redhat.com>
> > Cc: Alexander Graf <graf@amazon.com>
> > Cc: Steven Chen <chenste@linux.microsoft.com>
> > Cc: linux-integrity@vger.kernel.org
> > Cc: <stable@vger.kernel.org>
> > To: kexec@lists.infradead.org
> > ---
> > v1 -> v2:
> > return page_address(page) instead of *page
> >
> >  kernel/kexec_core.c | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index 9a1966207041..332204204e53 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -967,6 +967,7 @@ void *kimage_map_segment(struct kimage *image, int idx)
> >       kimage_entry_t *ptr, entry;
> >       struct page **src_pages;
> >       unsigned int npages;
> > +     struct page *cma;
> >       void *vaddr = NULL;
> >       int i;
> >
> > @@ -974,6 +975,9 @@ void *kimage_map_segment(struct kimage *image, int idx)
> >       size = image->segment[idx].memsz;
> >       eaddr = addr + size;
> >
> > +     cma = image->segment_cma[idx];
> > +     if (cma)
> > +             return page_address(cma);
> >       /*
> >        * Collect the source pages and map them in a contiguous VA range.
> >        */
> > @@ -1014,7 +1018,8 @@ void *kimage_map_segment(struct kimage *image, int idx)
> >
> >  void kimage_unmap_segment(void *segment_buffer)
> >  {
> > -     vunmap(segment_buffer);
> > +     if (is_vmalloc_addr(segment_buffer))
> > +             vunmap(segment_buffer);
> >  }
> >
> >  struct kexec_load_limit {
> > --
> > 2.49.0
> >
>

Re: [PATCHv2 2/2] kernel/kexec: Fix IMA when allocation happens in CMA area

[Baoquan He]

On 11/06/25 at 06:01pm, Pingfan Liu wrote:
> On Thu, Nov 6, 2025 at 4:01 PM Baoquan He <bhe@redhat.com> wrote:
> >
> > On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > > When I tested kexec with the latest kernel, I ran into the following warning:
> > >
> > > [   40.712410] ------------[ cut here ]------------
> > > [   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198
> > > [...]
> > > [   40.816047] Call trace:
> > > [   40.818498]  kimage_map_segment+0x144/0x198 (P)
> > > [   40.823221]  ima_kexec_post_load+0x58/0xc0
> > > [   40.827246]  __do_sys_kexec_file_load+0x29c/0x368
> > > [...]
> > > [   40.855423] ---[ end trace 0000000000000000 ]---
> > >
> > > This is caused by the fact that kexec allocates the destination directly
> > > in the CMA area. In that case, the CMA kernel address should be exported
> > > directly to the IMA component, instead of using the vmalloc'd address.
> >
> > Well, you didn't update the log accordingly.
> >
> 
> I am not sure what you mean. Do you mean the earlier content which I
> replied to you?

No. In v1, you return cma directly. But in v2, you return its direct
mapping address, isnt' it?

> 
> > Do you know why cma area can't be mapped into vmalloc?
> >
> Should not the kernel direct mapping be used?

When image->segment_cma[i] has value, image->ima_buffer_addr also
contains the physical address of the cma area, why cma physical address
can't be mapped into vmalloc and cause the failure and call trace?

Re: [PATCHv2 2/2] kernel/kexec: Fix IMA when allocation happens in CMA area

[Pingfan Liu]

On Fri, Nov 7, 2025 at 9:51 AM Baoquan He <bhe@redhat.com> wrote:
>
> On 11/06/25 at 06:01pm, Pingfan Liu wrote:
> > On Thu, Nov 6, 2025 at 4:01 PM Baoquan He <bhe@redhat.com> wrote:
> > >
> > > On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > > > When I tested kexec with the latest kernel, I ran into the following warning:
> > > >
> > > > [   40.712410] ------------[ cut here ]------------
> > > > [   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198
> > > > [...]
> > > > [   40.816047] Call trace:
> > > > [   40.818498]  kimage_map_segment+0x144/0x198 (P)
> > > > [   40.823221]  ima_kexec_post_load+0x58/0xc0
> > > > [   40.827246]  __do_sys_kexec_file_load+0x29c/0x368
> > > > [...]
> > > > [   40.855423] ---[ end trace 0000000000000000 ]---
> > > >
> > > > This is caused by the fact that kexec allocates the destination directly
> > > > in the CMA area. In that case, the CMA kernel address should be exported
> > > > directly to the IMA component, instead of using the vmalloc'd address.
> > >
> > > Well, you didn't update the log accordingly.
> > >
> >
> > I am not sure what you mean. Do you mean the earlier content which I
> > replied to you?
>
> No. In v1, you return cma directly. But in v2, you return its direct
> mapping address, isnt' it?
>

Yes. But I think it is a fault in the code, which does not convey the
expression in the commit log. Do you think I should rephrase the words
"the CMA kernel address" as "the CMA kernel direct mapping address"?

> >
> > > Do you know why cma area can't be mapped into vmalloc?
> > >
> > Should not the kernel direct mapping be used?
>
> When image->segment_cma[i] has value, image->ima_buffer_addr also
> contains the physical address of the cma area, why cma physical address
> can't be mapped into vmalloc and cause the failure and call trace?
>

It could be done using the vmalloc approach, but it's unnecessary.
IIUC, kimage_map_segment() was introduced to provide a contiguous
virtual address for IMA access, since the IND_SRC pages are scattered
throughout the kernel. However, in the CMA case, there is already a
contiguous virtual address in the kernel direct mapping range.
Normally, when we have a physical address, we simply use
phys_to_virt() to get its corresponding kernel virtual address.

Thanks,

Pingfan

Re: [PATCHv2 2/2] kernel/kexec: Fix IMA when allocation happens in CMA area

[Baoquan He]

On 11/07/25 at 01:13pm, Pingfan Liu wrote:
> On Fri, Nov 7, 2025 at 9:51 AM Baoquan He <bhe@redhat.com> wrote:
> >
> > On 11/06/25 at 06:01pm, Pingfan Liu wrote:
> > > On Thu, Nov 6, 2025 at 4:01 PM Baoquan He <bhe@redhat.com> wrote:
> > > >
> > > > On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > > > > When I tested kexec with the latest kernel, I ran into the following warning:
> > > > >
> > > > > [   40.712410] ------------[ cut here ]------------
> > > > > [   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198
> > > > > [...]
> > > > > [   40.816047] Call trace:
> > > > > [   40.818498]  kimage_map_segment+0x144/0x198 (P)
> > > > > [   40.823221]  ima_kexec_post_load+0x58/0xc0
> > > > > [   40.827246]  __do_sys_kexec_file_load+0x29c/0x368
> > > > > [...]
> > > > > [   40.855423] ---[ end trace 0000000000000000 ]---
> > > > >
> > > > > This is caused by the fact that kexec allocates the destination directly
> > > > > in the CMA area. In that case, the CMA kernel address should be exported
> > > > > directly to the IMA component, instead of using the vmalloc'd address.
> > > >
> > > > Well, you didn't update the log accordingly.
> > > >
> > >
> > > I am not sure what you mean. Do you mean the earlier content which I
> > > replied to you?
> >
> > No. In v1, you return cma directly. But in v2, you return its direct
> > mapping address, isnt' it?
> >
> 
> Yes. But I think it is a fault in the code, which does not convey the
> expression in the commit log. Do you think I should rephrase the words
> "the CMA kernel address" as "the CMA kernel direct mapping address"?

That's fine to me.

> 
> > >
> > > > Do you know why cma area can't be mapped into vmalloc?
> > > >
> > > Should not the kernel direct mapping be used?
> >
> > When image->segment_cma[i] has value, image->ima_buffer_addr also
> > contains the physical address of the cma area, why cma physical address
> > can't be mapped into vmalloc and cause the failure and call trace?
> >
> 
> It could be done using the vmalloc approach, but it's unnecessary.
> IIUC, kimage_map_segment() was introduced to provide a contiguous
> virtual address for IMA access, since the IND_SRC pages are scattered
> throughout the kernel. However, in the CMA case, there is already a
> contiguous virtual address in the kernel direct mapping range.
> Normally, when we have a physical address, we simply use
> phys_to_virt() to get its corresponding kernel virtual address.

OK, I understand cma area is contiguous, and no need to map into
vmalloc. I am wondering why in the old code mapping cma addrss into 
vmalloc cause the warning which you said is a IMA problem. 

Re: [PATCHv2 2/2] kernel/kexec: Fix IMA when allocation happens in CMA area

[Pingfan Liu]

On Fri, Nov 07, 2025 at 01:25:41PM +0800, Baoquan He wrote:
> On 11/07/25 at 01:13pm, Pingfan Liu wrote:
> > On Fri, Nov 7, 2025 at 9:51 AM Baoquan He <bhe@redhat.com> wrote:
> > >
> > > On 11/06/25 at 06:01pm, Pingfan Liu wrote:
> > > > On Thu, Nov 6, 2025 at 4:01 PM Baoquan He <bhe@redhat.com> wrote:
> > > > >
> > > > > On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > > > > > When I tested kexec with the latest kernel, I ran into the following warning:
> > > > > >
> > > > > > [   40.712410] ------------[ cut here ]------------
> > > > > > [   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198
> > > > > > [...]
> > > > > > [   40.816047] Call trace:
> > > > > > [   40.818498]  kimage_map_segment+0x144/0x198 (P)
> > > > > > [   40.823221]  ima_kexec_post_load+0x58/0xc0
> > > > > > [   40.827246]  __do_sys_kexec_file_load+0x29c/0x368
> > > > > > [...]
> > > > > > [   40.855423] ---[ end trace 0000000000000000 ]---
> > > > > >
> > > > > > This is caused by the fact that kexec allocates the destination directly
> > > > > > in the CMA area. In that case, the CMA kernel address should be exported
> > > > > > directly to the IMA component, instead of using the vmalloc'd address.
> > > > >
> > > > > Well, you didn't update the log accordingly.
> > > > >
> > > >
> > > > I am not sure what you mean. Do you mean the earlier content which I
> > > > replied to you?
> > >
> > > No. In v1, you return cma directly. But in v2, you return its direct
> > > mapping address, isnt' it?
> > >
> > 
> > Yes. But I think it is a fault in the code, which does not convey the
> > expression in the commit log. Do you think I should rephrase the words
> > "the CMA kernel address" as "the CMA kernel direct mapping address"?
> 
> That's fine to me.
> 
> > 
> > > >
> > > > > Do you know why cma area can't be mapped into vmalloc?
> > > > >
> > > > Should not the kernel direct mapping be used?
> > >
> > > When image->segment_cma[i] has value, image->ima_buffer_addr also
> > > contains the physical address of the cma area, why cma physical address
> > > can't be mapped into vmalloc and cause the failure and call trace?
> > >
> > 
> > It could be done using the vmalloc approach, but it's unnecessary.
> > IIUC, kimage_map_segment() was introduced to provide a contiguous
> > virtual address for IMA access, since the IND_SRC pages are scattered
> > throughout the kernel. However, in the CMA case, there is already a
> > contiguous virtual address in the kernel direct mapping range.
> > Normally, when we have a physical address, we simply use
> > phys_to_virt() to get its corresponding kernel virtual address.
> 
> OK, I understand cma area is contiguous, and no need to map into
> vmalloc. I am wondering why in the old code mapping cma addrss into 
> vmalloc cause the warning which you said is a IMA problem. 
> 

It doesn't go that far. The old code doesn't map CMA into vmalloc'd
area.

void *kimage_map_segment(struct kimage *image, int idx)
{
	...
        for_each_kimage_entry(image, ptr, entry) {
                if (entry & IND_DESTINATION) {
                        dest_page_addr = entry & PAGE_MASK;
                } else if (entry & IND_SOURCE) {
                        if (dest_page_addr >= addr && dest_page_addr < eaddr) {
                                src_page_addr = entry & PAGE_MASK;
                                src_pages[i++] =
                                        virt_to_page(__va(src_page_addr));
                                if (i == npages)
                                        break;
                                dest_page_addr += PAGE_SIZE;
                        }
                }
        }

        /* Sanity check. */
        WARN_ON(i < npages);     //--> This is the warning thrown by kernel

        vaddr = vmap(src_pages, npages, VM_MAP, PAGE_KERNEL);
        kfree(src_pages);

        if (!vaddr)
                pr_err("Could not map ima buffer.\n");

        return vaddr;
}

When CMA is used, there is no IND_SOURCE, so we have i=0 < npages.
Now, I see how my words ("In that case, the CMA kernel address should be
exported directly to the IMA component, instead of using the vmalloc'd
address.") confused you. As for "instead of using the vmalloc'd
address", I meant to mention "vmap()" approach.


Best Regards,

Pingfan

Re: [PATCHv2 2/2] kernel/kexec: Fix IMA when allocation happens in CMA area

[Baoquan He]

On 11/07/25 at 05:00pm, Pingfan Liu wrote:
> On Fri, Nov 07, 2025 at 01:25:41PM +0800, Baoquan He wrote:
> > On 11/07/25 at 01:13pm, Pingfan Liu wrote:
> > > On Fri, Nov 7, 2025 at 9:51 AM Baoquan He <bhe@redhat.com> wrote:
> > > >
> > > > On 11/06/25 at 06:01pm, Pingfan Liu wrote:
> > > > > On Thu, Nov 6, 2025 at 4:01 PM Baoquan He <bhe@redhat.com> wrote:
> > > > > >
> > > > > > On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > > > > > > When I tested kexec with the latest kernel, I ran into the following warning:
> > > > > > >
> > > > > > > [   40.712410] ------------[ cut here ]------------
> > > > > > > [   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198
> > > > > > > [...]
> > > > > > > [   40.816047] Call trace:
> > > > > > > [   40.818498]  kimage_map_segment+0x144/0x198 (P)
> > > > > > > [   40.823221]  ima_kexec_post_load+0x58/0xc0
> > > > > > > [   40.827246]  __do_sys_kexec_file_load+0x29c/0x368
> > > > > > > [...]
> > > > > > > [   40.855423] ---[ end trace 0000000000000000 ]---
> > > > > > >
> > > > > > > This is caused by the fact that kexec allocates the destination directly
> > > > > > > in the CMA area. In that case, the CMA kernel address should be exported
> > > > > > > directly to the IMA component, instead of using the vmalloc'd address.
> > > > > >
> > > > > > Well, you didn't update the log accordingly.
> > > > > >
> > > > >
> > > > > I am not sure what you mean. Do you mean the earlier content which I
> > > > > replied to you?
> > > >
> > > > No. In v1, you return cma directly. But in v2, you return its direct
> > > > mapping address, isnt' it?
> > > >
> > > 
> > > Yes. But I think it is a fault in the code, which does not convey the
> > > expression in the commit log. Do you think I should rephrase the words
> > > "the CMA kernel address" as "the CMA kernel direct mapping address"?
> > 
> > That's fine to me.
> > 
> > > 
> > > > >
> > > > > > Do you know why cma area can't be mapped into vmalloc?
> > > > > >
> > > > > Should not the kernel direct mapping be used?
> > > >
> > > > When image->segment_cma[i] has value, image->ima_buffer_addr also
> > > > contains the physical address of the cma area, why cma physical address
> > > > can't be mapped into vmalloc and cause the failure and call trace?
> > > >
> > > 
> > > It could be done using the vmalloc approach, but it's unnecessary.
> > > IIUC, kimage_map_segment() was introduced to provide a contiguous
> > > virtual address for IMA access, since the IND_SRC pages are scattered
> > > throughout the kernel. However, in the CMA case, there is already a
> > > contiguous virtual address in the kernel direct mapping range.
> > > Normally, when we have a physical address, we simply use
> > > phys_to_virt() to get its corresponding kernel virtual address.
> > 
> > OK, I understand cma area is contiguous, and no need to map into
> > vmalloc. I am wondering why in the old code mapping cma addrss into 
> > vmalloc cause the warning which you said is a IMA problem. 
> > 
> 
> It doesn't go that far. The old code doesn't map CMA into vmalloc'd
> area.
> 
> void *kimage_map_segment(struct kimage *image, int idx)
> {
> 	...
>         for_each_kimage_entry(image, ptr, entry) {
>                 if (entry & IND_DESTINATION) {
>                         dest_page_addr = entry & PAGE_MASK;
>                 } else if (entry & IND_SOURCE) {
>                         if (dest_page_addr >= addr && dest_page_addr < eaddr) {
>                                 src_page_addr = entry & PAGE_MASK;
>                                 src_pages[i++] =
>                                         virt_to_page(__va(src_page_addr));
>                                 if (i == npages)
>                                         break;
>                                 dest_page_addr += PAGE_SIZE;
>                         }
>                 }
>         }
> 
>         /* Sanity check. */
>         WARN_ON(i < npages);     //--> This is the warning thrown by kernel
> 
>         vaddr = vmap(src_pages, npages, VM_MAP, PAGE_KERNEL);
>         kfree(src_pages);
> 
>         if (!vaddr)
>                 pr_err("Could not map ima buffer.\n");
> 
>         return vaddr;
> }
> 
> When CMA is used, there is no IND_SOURCE, so we have i=0 < npages.
> Now, I see how my words ("In that case, the CMA kernel address should be
> exported directly to the IMA component, instead of using the vmalloc'd
> address.") confused you. As for "instead of using the vmalloc'd
> address", I meant to mention "vmap()" approach.

Ok, I got it. It's truly a bug because if image->segment_cma[idx] is
valid, the current kimage_map_segment() can't collect the source pages
at all since they are not marked with IND_DESTINATION|IND_SOURCE as
normal segment does. In that situation, we can take the direct mapping
address of image->segment_cma[idx] which is more efficient, instead of
collecting source pages and vmap().

Re: [PATCHv2 2/2] kernel/kexec: Fix IMA when allocation happens in CMA area

[Baoquan He]

On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> When I tested kexec with the latest kernel, I ran into the following warning:
> 
> [   40.712410] ------------[ cut here ]------------
> [   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198
> [...]
> [   40.816047] Call trace:
> [   40.818498]  kimage_map_segment+0x144/0x198 (P)
> [   40.823221]  ima_kexec_post_load+0x58/0xc0
> [   40.827246]  __do_sys_kexec_file_load+0x29c/0x368
> [...]
> [   40.855423] ---[ end trace 0000000000000000 ]---
> 
> This is caused by the fact that kexec allocates the destination directly
> in the CMA area. In that case, the CMA kernel address should be exported
> directly to the IMA component, instead of using the vmalloc'd address.
> 
> Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> Signed-off-by: Pingfan Liu <piliu@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Alexander Graf <graf@amazon.com>
> Cc: Steven Chen <chenste@linux.microsoft.com>
> Cc: linux-integrity@vger.kernel.org
> Cc: <stable@vger.kernel.org>
> To: kexec@lists.infradead.org
> ---
> v1 -> v2:
> return page_address(page) instead of *page
> 
>  kernel/kexec_core.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 9a1966207041..332204204e53 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -967,6 +967,7 @@ void *kimage_map_segment(struct kimage *image, int idx)
>  	kimage_entry_t *ptr, entry;
>  	struct page **src_pages;
>  	unsigned int npages;
> +	struct page *cma;
>  	void *vaddr = NULL;
>  	int i;
>  
> @@ -974,6 +975,9 @@ void *kimage_map_segment(struct kimage *image, int idx)
>  	size = image->segment[idx].memsz;
>  	eaddr = addr + size;
>  
> +	cma = image->segment_cma[idx];
> +	if (cma)
> +		return page_address(cma);

This judgement can be put above the addr/size/eaddr assignment lines?

If you agree, maybe you can update the patch log by adding more details
to explain the root cause so that people can understand it easier.

>  	/*
>  	 * Collect the source pages and map them in a contiguous VA range.
>  	 */
> @@ -1014,7 +1018,8 @@ void *kimage_map_segment(struct kimage *image, int idx)
>  
>  void kimage_unmap_segment(void *segment_buffer)
>  {
> -	vunmap(segment_buffer);
> +	if (is_vmalloc_addr(segment_buffer))
> +		vunmap(segment_buffer);
>  }
>  
>  struct kexec_load_limit {
> -- 
> 2.49.0
> 

Re: [PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Andrew Morton]

On Thu,  6 Nov 2025 14:59:03 +0800 Pingfan Liu <piliu@redhat.com> wrote:

> The kexec segment index will be required to extract the corresponding
> information for that segment in kimage_map_segment(). Additionally,
> kexec_segment already holds the kexec relocation destination address and
> size. Therefore, the prototype of kimage_map_segment() can be changed.

Could we please have some reviewer input on thee two patches?

Thanks.

(Pingfan, please cc linux-kernel on patches - it's where people go to
find emails on lists which they aren't suscribed to)

(akpm goes off and subscribes to kexec@)

> Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> Signed-off-by: Pingfan Liu <piliu@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Mimi Zohar <zohar@linux.ibm.com>
> Cc: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: Alexander Graf <graf@amazon.com>
> Cc: Steven Chen <chenste@linux.microsoft.com>
> Cc: <stable@vger.kernel.org>
> To: kexec@lists.infradead.org
> To: linux-integrity@vger.kernel.org
> ---
>  include/linux/kexec.h              | 4 ++--
>  kernel/kexec_core.c                | 9 ++++++---
>  security/integrity/ima/ima_kexec.c | 4 +---
>  3 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index ff7e231b0485..8a22bc9b8c6c 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print;
>  #define kexec_dprintk(fmt, arg...) \
>          do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
>  
> -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
> +extern void *kimage_map_segment(struct kimage *image, int idx);
>  extern void kimage_unmap_segment(void *buffer);
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
> @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
>  static inline void crash_kexec(struct pt_regs *regs) { }
>  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
>  static inline int kexec_crash_loaded(void) { return 0; }
> -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
> +static inline void *kimage_map_segment(struct kimage *image, int idx)
>  { return NULL; }
>  static inline void kimage_unmap_segment(void *buffer) { }
>  #define kexec_in_progress false
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index fa00b239c5d9..9a1966207041 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *image, int idx)
>  	return result;
>  }
>  
> -void *kimage_map_segment(struct kimage *image,
> -			 unsigned long addr, unsigned long size)
> +void *kimage_map_segment(struct kimage *image, int idx)
>  {
> +	unsigned long addr, size, eaddr;
>  	unsigned long src_page_addr, dest_page_addr = 0;
> -	unsigned long eaddr = addr + size;
>  	kimage_entry_t *ptr, entry;
>  	struct page **src_pages;
>  	unsigned int npages;
>  	void *vaddr = NULL;
>  	int i;
>  
> +	addr = image->segment[idx].mem;
> +	size = image->segment[idx].memsz;
> +	eaddr = addr + size;
> +
>  	/*
>  	 * Collect the source pages and map them in a contiguous VA range.
>  	 */
> diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> index 7362f68f2d8b..5beb69edd12f 100644
> --- a/security/integrity/ima/ima_kexec.c
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image)
>  	if (!image->ima_buffer_addr)
>  		return;
>  
> -	ima_kexec_buffer = kimage_map_segment(image,
> -					      image->ima_buffer_addr,
> -					      image->ima_buffer_size);
> +	ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index);
>  	if (!ima_kexec_buffer) {
>  		pr_err("Could not map measurements buffer.\n");
>  		return;
> -- 
> 2.49.0

Re: [PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Pingfan Liu]

On Tue, Nov 25, 2025 at 6:16 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu,  6 Nov 2025 14:59:03 +0800 Pingfan Liu <piliu@redhat.com> wrote:
>
> > The kexec segment index will be required to extract the corresponding
> > information for that segment in kimage_map_segment(). Additionally,
> > kexec_segment already holds the kexec relocation destination address and
> > size. Therefore, the prototype of kimage_map_segment() can be changed.
>
> Could we please have some reviewer input on thee two patches?
>
> Thanks.
>
> (Pingfan, please cc linux-kernel on patches - it's where people go to
> find emails on lists which they aren't suscribed to)
>
OK, I will cc linux-kernel for the future kexec patches

For this series, it can also be found on
https://lore.kernel.org/linux-integrity/20251106065904.10772-1-piliu@redhat.com/

Thanks,

Pingfan

> (akpm goes off and subscribes to kexec@)
>
> > Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> > Signed-off-by: Pingfan Liu <piliu@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Baoquan He <bhe@redhat.com>
> > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > Cc: Roberto Sassu <roberto.sassu@huawei.com>
> > Cc: Alexander Graf <graf@amazon.com>
> > Cc: Steven Chen <chenste@linux.microsoft.com>
> > Cc: <stable@vger.kernel.org>
> > To: kexec@lists.infradead.org
> > To: linux-integrity@vger.kernel.org
> > ---
> >  include/linux/kexec.h              | 4 ++--
> >  kernel/kexec_core.c                | 9 ++++++---
> >  security/integrity/ima/ima_kexec.c | 4 +---
> >  3 files changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > index ff7e231b0485..8a22bc9b8c6c 100644
> > --- a/include/linux/kexec.h
> > +++ b/include/linux/kexec.h
> > @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print;
> >  #define kexec_dprintk(fmt, arg...) \
> >          do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
> >
> > -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
> > +extern void *kimage_map_segment(struct kimage *image, int idx);
> >  extern void kimage_unmap_segment(void *buffer);
> >  #else /* !CONFIG_KEXEC_CORE */
> >  struct pt_regs;
> > @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
> >  static inline void crash_kexec(struct pt_regs *regs) { }
> >  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
> >  static inline int kexec_crash_loaded(void) { return 0; }
> > -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
> > +static inline void *kimage_map_segment(struct kimage *image, int idx)
> >  { return NULL; }
> >  static inline void kimage_unmap_segment(void *buffer) { }
> >  #define kexec_in_progress false
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index fa00b239c5d9..9a1966207041 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *image, int idx)
> >       return result;
> >  }
> >
> > -void *kimage_map_segment(struct kimage *image,
> > -                      unsigned long addr, unsigned long size)
> > +void *kimage_map_segment(struct kimage *image, int idx)
> >  {
> > +     unsigned long addr, size, eaddr;
> >       unsigned long src_page_addr, dest_page_addr = 0;
> > -     unsigned long eaddr = addr + size;
> >       kimage_entry_t *ptr, entry;
> >       struct page **src_pages;
> >       unsigned int npages;
> >       void *vaddr = NULL;
> >       int i;
> >
> > +     addr = image->segment[idx].mem;
> > +     size = image->segment[idx].memsz;
> > +     eaddr = addr + size;
> > +
> >       /*
> >        * Collect the source pages and map them in a contiguous VA range.
> >        */
> > diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> > index 7362f68f2d8b..5beb69edd12f 100644
> > --- a/security/integrity/ima/ima_kexec.c
> > +++ b/security/integrity/ima/ima_kexec.c
> > @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image)
> >       if (!image->ima_buffer_addr)
> >               return;
> >
> > -     ima_kexec_buffer = kimage_map_segment(image,
> > -                                           image->ima_buffer_addr,
> > -                                           image->ima_buffer_size);
> > +     ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index);
> >       if (!ima_kexec_buffer) {
> >               pr_err("Could not map measurements buffer.\n");
> >               return;
> > --
> > 2.49.0
>

Re: [PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Baoquan He]

On 11/24/25 at 02:16pm, Andrew Morton wrote:
> On Thu,  6 Nov 2025 14:59:03 +0800 Pingfan Liu <piliu@redhat.com> wrote:
> 
> > The kexec segment index will be required to extract the corresponding
> > information for that segment in kimage_map_segment(). Additionally,
> > kexec_segment already holds the kexec relocation destination address and
> > size. Therefore, the prototype of kimage_map_segment() can be changed.
> 
> Could we please have some reviewer input on thee two patches?

I have some concerns about the one place of tiny code change, and the
root cause missing in log. And Mimi sent mail to me asking why this bug
can'e be seen on her laptop, I told her this bug can only be triggered
on system where CMA area exists. I think these need be addressed in v3.

> 
> (Pingfan, please cc linux-kernel on patches - it's where people go to
> find emails on lists which they aren't suscribed to)
> 
> (akpm goes off and subscribes to kexec@)
> 
> > Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> > Signed-off-by: Pingfan Liu <piliu@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Baoquan He <bhe@redhat.com>
> > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > Cc: Roberto Sassu <roberto.sassu@huawei.com>
> > Cc: Alexander Graf <graf@amazon.com>
> > Cc: Steven Chen <chenste@linux.microsoft.com>
> > Cc: <stable@vger.kernel.org>
> > To: kexec@lists.infradead.org
> > To: linux-integrity@vger.kernel.org
> > ---
> >  include/linux/kexec.h              | 4 ++--
> >  kernel/kexec_core.c                | 9 ++++++---
> >  security/integrity/ima/ima_kexec.c | 4 +---
> >  3 files changed, 9 insertions(+), 8 deletions(-)
> > 
> > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > index ff7e231b0485..8a22bc9b8c6c 100644
> > --- a/include/linux/kexec.h
> > +++ b/include/linux/kexec.h
> > @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print;
> >  #define kexec_dprintk(fmt, arg...) \
> >          do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
> >  
> > -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
> > +extern void *kimage_map_segment(struct kimage *image, int idx);
> >  extern void kimage_unmap_segment(void *buffer);
> >  #else /* !CONFIG_KEXEC_CORE */
> >  struct pt_regs;
> > @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
> >  static inline void crash_kexec(struct pt_regs *regs) { }
> >  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
> >  static inline int kexec_crash_loaded(void) { return 0; }
> > -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
> > +static inline void *kimage_map_segment(struct kimage *image, int idx)
> >  { return NULL; }
> >  static inline void kimage_unmap_segment(void *buffer) { }
> >  #define kexec_in_progress false
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index fa00b239c5d9..9a1966207041 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *image, int idx)
> >  	return result;
> >  }
> >  
> > -void *kimage_map_segment(struct kimage *image,
> > -			 unsigned long addr, unsigned long size)
> > +void *kimage_map_segment(struct kimage *image, int idx)
> >  {
> > +	unsigned long addr, size, eaddr;
> >  	unsigned long src_page_addr, dest_page_addr = 0;
> > -	unsigned long eaddr = addr + size;
> >  	kimage_entry_t *ptr, entry;
> >  	struct page **src_pages;
> >  	unsigned int npages;
> >  	void *vaddr = NULL;
> >  	int i;
> >  
> > +	addr = image->segment[idx].mem;
> > +	size = image->segment[idx].memsz;
> > +	eaddr = addr + size;
> > +
> >  	/*
> >  	 * Collect the source pages and map them in a contiguous VA range.
> >  	 */
> > diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> > index 7362f68f2d8b..5beb69edd12f 100644
> > --- a/security/integrity/ima/ima_kexec.c
> > +++ b/security/integrity/ima/ima_kexec.c
> > @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image)
> >  	if (!image->ima_buffer_addr)
> >  		return;
> >  
> > -	ima_kexec_buffer = kimage_map_segment(image,
> > -					      image->ima_buffer_addr,
> > -					      image->ima_buffer_size);
> > +	ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index);
> >  	if (!ima_kexec_buffer) {
> >  		pr_err("Could not map measurements buffer.\n");
> >  		return;
> > -- 
> > 2.49.0
> 

Re: [PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Andrew Morton]

On Tue, 25 Nov 2025 12:54:39 +0800 Baoquan He <bhe@redhat.com> wrote:

> On 11/24/25 at 02:16pm, Andrew Morton wrote:
> > On Thu,  6 Nov 2025 14:59:03 +0800 Pingfan Liu <piliu@redhat.com> wrote:
> > 
> > > The kexec segment index will be required to extract the corresponding
> > > information for that segment in kimage_map_segment(). Additionally,
> > > kexec_segment already holds the kexec relocation destination address and
> > > size. Therefore, the prototype of kimage_map_segment() can be changed.
> > 
> > Could we please have some reviewer input on thee two patches?
> 
> I have some concerns about the one place of tiny code change, and the
> root cause missing in log. And Mimi sent mail to me asking why this bug
> can'e be seen on her laptop, I told her this bug can only be triggered
> on system where CMA area exists. I think these need be addressed in v3.

Great, thanks, I'll drop this version.

Re: [PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Baoquan He]

Hi Pingfan,

On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> The kexec segment index will be required to extract the corresponding
> information for that segment in kimage_map_segment(). Additionally,
> kexec_segment already holds the kexec relocation destination address and
> size. Therefore, the prototype of kimage_map_segment() can be changed.

Because no cover letter, I just reply here.

I am testing code of (tag: next-20251125, next/master) on arm64 system.
I saw your two patches are already in there. When I used kexec reboot
as below, I still got the warning message during ima_kexec_post_load()
invocation. 

====================
kexec -d -l /boot/vmlinuz-6.18.0-rc7-next-20251125 --initrd /boot/initramfs-6.18.0-rc7-next-20251125.img --reuse-cmdline
====================

====================
[34283.657670] kexec_file: kernel: 000000006cf71829 kernel_size: 0x48b0000
[34283.657700] PEFILE: Unsigned PE binary
[34283.676597] ima: kexec measurement buffer for the loaded kernel at 0xff206000.
[34283.676621] kexec_file: Loaded initrd at 0x84cb0000 bufsz=0x25ec426 memsz=0x25ed000
[34283.684646] kexec_file: Loaded dtb at 0xff400000 bufsz=0x39e memsz=0x1000
[34283.684653] kexec_file(Image): Loaded kernel at 0x80400000 bufsz=0x48b0000 memsz=0x48b0000
[34283.684663] kexec_file: nr_segments = 4
[34283.684666] kexec_file: segment[0]: buf=0x0000000000000000 bufsz=0x0 mem=0xff206000 memsz=0x1000
[34283.684674] kexec_file: segment[1]: buf=0x000000006cf71829 bufsz=0x48b0000 mem=0x80400000 memsz=0x48b0000
[34283.725987] kexec_file: segment[2]: buf=0x00000000c7369de6 bufsz=0x25ec426 mem=0x84cb0000 memsz=0x25ed000
[34283.747670] kexec_file: segmen
** replaying previous printk message **
[34283.747670] kexec_file: segment[3]: buf=0x00000000d83b530b bufsz=0x39e mem=0xff400000 memsz=0x1000
[34283.747973] ------------[ cut here ]------------
[34283.747976] WARNING: CPU: 33 PID: 16112 at kernel/kexec_core.c:1002 kimage_map_segment+0x138/0x190
[34283.778574] Modules linked in: rfkill vfat fat ipmi_ssif igb acpi_ipmi ipmi_si ipmi_devintf mlx5_fwctl i2c_algo_bit ipmi_msghandler fwctl fuse loop nfnetlink zram lz4hc_compress lz4_compress xfs mlx5_ib macsec mlx5_core nvme nvme_core mlxfw psample tls nvme_keyring nvme_auth pci_hyperv_intf sbsa_gwdt rpcrdma sunrpc rdma_ucm ib_uverbs ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser i2c_dev ib_umad rdma_cm ib_ipoib iw_cm ib_cm libiscsi ib_core scsi_transport_iscsi aes_neon_bs
[34283.824233] CPU: 33 UID: 0 PID: 16112 Comm: kexec Tainted: G        W           6.17.8-200.fc42.aarch64 #1 PREEMPT(voluntary) 
[34283.836355] Tainted: [W]=WARN
[34283.839684] Hardware name: CRAY CS500/CMUD        , BIOS 1.4.0 Jun 17 2020
[34283.846903] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[34283.854243] pc : kimage_map_segment+0x138/0x190
[34283.859120] lr : kimage_map_segment+0x4c/0x190
[34283.863920] sp : ffff8000a0643a90
[34283.867394] x29: ffff8000a0643a90 x28: ffff800083d0a000 x27: 0000000000000000
[34283.874901] x26: 0000aaaad722d4b0 x25: 000000000000008f x24: ffff800083d0a000
[34283.882608] x23: 0000000000000001 x22: 00000000ff206000 x21: 00000000ff207000
[34283.890305] x20: ffff008fbd306980 x19: ffff008f895d6400 x18: 00000000fffffff9
[34283.897815] x17: 303d6d656d206539 x16: 3378303d7a736675 x15: 646565732d676e72
[34283.905516] x14: 00646565732d726c x13: 616d692c78756e69 x12: 6c00636578656b2d
[34283.912999] x11: 007265666675622d x10: 636578656b2d616d x9 : ffff80008050b73c
[34283.920691] x8 : 0001000000000000 x7 : 0000000000000000 x6 : 0000000080000000
[34283.928197] x5 : 0000000084cb0000 x4 : ffff008fbd2306b0 x3 : ffff008fbd305000
[34283.935898] x2 : fffffff7ff000000 x1 : 0000000000000004 x0 : ffff800082046000
[34283.943603] Call trace:
[34283.946039]  kimage_map_segment+0x138/0x190 (P)
[34283.950935]  ima_kexec_post_load+0x58/0xc0
[34283.955225]  __do_sys_kexec_file_load+0x2b8/0x398
[34283.960279]  __arm64_sys_kexec_file_load+0x28/0x40
[34283.965965]  invoke_syscall.constprop.0+0x64/0xe8
[34283.971025]  el0_svc_common.constprop.0+0x40/0xe8
[34283.975883]  do_el0_svc+0x24/0x38
[34283.979361]  el0_svc+0x3c/0x168
[34283.982833]  el0t_64_sync_handler+0xa0/0xf0
[34283.987176]  el0t_64_sync+0x1b0/0x1b8
[34283.991000] ---[ end trace 0000000000000000 ]---
[34283.996060] ------------[ cut here ]------------
[34283.996064] WARNING: CPU: 33 PID: 16112 at mm/vmalloc.c:538 vmap_pages_pte_range+0x2bc/0x3c0
[34284.010006] Modules linked in: rfkill vfat fat ipmi_ssif igb acpi_ipmi ipmi_si ipmi_devintf mlx5_fwctl i2c_algo_bit ipmi_msghandler fwctl fuse loop nfnetlink zram lz4hc_compress lz4_compress xfs mlx5_ib macsec mlx5_core nvme nvme_core mlxfw psample tls nvme_keyring nvme_auth pci_hyperv_intf sbsa_gwdt rpcrdma sunrpc rdma_ucm ib_uverbs ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser i2c_dev ib_umad rdma_cm ib_ipoib iw_cm ib_cm libiscsi ib_core scsi_transport_iscsi aes_neon_bs
[34284.055630] CPU: 33 UID: 0 PID: 16112 Comm: kexec Tainted: G        W           6.17.8-200.fc42.aarch64 #1 PREEMPT(voluntary) 
[34284.067701] Tainted: [W]=WARN
[34284.070833] Hardware name: CRAY CS500/CMUD        , BIOS 1.4.0 Jun 17 2020
[34284.078238] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[34284.085546] pc : vmap_pages_pte_range+0x2bc/0x3c0
[34284.090607] lr : vmap_small_pages_range_noflush+0x16c/0x298
[34284.096528] sp : ffff8000a0643940
[34284.100001] x29: ffff8000a0643940 x28: 0000000000000000 x27: ffff800084f76000
[34284.107699] x26: fffffdffc0000000 x25: ffff8000a06439d0 x24: ffff800082046000
[34284.115174] x23: ffff800084f75000 x22: ffff007f80337ba8 x21: 03ffffffffffffc0
[34284.122821] x20: ffff008fbd306980 x19: ffff8000a06439d4 x18: 00000000fffffff9
[34284.130331] x17: 303d6d656d206539 x16: 3378303d7a736675 x15: 646565732d676e72
[34284.138032] x14: 0000000000004000 x13: ffff009781307130 x12: 0000000000002000
[34284.145733] x11: 0000000000000000 x10: 0000000000000001 x9 : ffff8000804e197c
[34284.153248] x8 : 0000000000000027 x7 : ffff800085175000 x6 : ffff8000a06439d4
[34284.160944] x5 : ffff8000a06439d0 x4 : ffff008fbd306980 x3 : 0068000000000f03
[34284.168449] x2 : ffff007f80337ba8 x1 : 0000000000000000 x0 : 0000000000000000
[34284.176150] Call trace:
[34284.178768]  vmap_pages_pte_range+0x2bc/0x3c0 (P)
[34284.183665]  vmap_small_pages_range_noflush+0x16c/0x298
[34284.189264]  vmap+0xb4/0x138
[34284.192312]  kimage_map_segment+0xdc/0x190
[34284.196794]  ima_kexec_post_load+0x58/0xc0
[34284.201044]  __do_sys_kexec_file_load+0x2b8/0x398
[34284.206107]  __arm64_sys_kexec_file_load+0x28/0x40
[34284.211254]  invoke_syscall.constprop.0+0x64/0xe8
[34284.216139]  el0_svc_common.constprop.0+0x40/0xe8
[34284.221196]  do_el0_svc+0x24/0x38
[34284.224678]  el0_svc+0x3c/0x168
[34284.227983]  el0t_64_sync_handler+0xa0/0xf0
[34284.232526]  el0t_64_sync+0x1b0/0x1b8
[34284.236376] ---[ end trace 0000000000000000 ]---
[34284.241412] kexec_core: Could not map ima buffer.
[34284.241421] ima: Could not map measurements buffer.
[34284.551336] machine_kexec_post_load:155:
[34284.551354]   kexec kimage info:
[34284.551366]     type:        0
[34284.551373]     head:        90363f9002
[34284.551377]     kern_reloc: 0x00000090363f7000
[34284.551381]     el2_vectors: 0x0000000000000000
[34284.551384] kexec_file: kexec_file_load: type:0, start:0x80400000 head:0x90363f9002 flags:0x8
====================

> 
> Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> Signed-off-by: Pingfan Liu <piliu@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Mimi Zohar <zohar@linux.ibm.com>
> Cc: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: Alexander Graf <graf@amazon.com>
> Cc: Steven Chen <chenste@linux.microsoft.com>
> Cc: <stable@vger.kernel.org>
> To: kexec@lists.infradead.org
> To: linux-integrity@vger.kernel.org
> ---
>  include/linux/kexec.h              | 4 ++--
>  kernel/kexec_core.c                | 9 ++++++---
>  security/integrity/ima/ima_kexec.c | 4 +---
>  3 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index ff7e231b0485..8a22bc9b8c6c 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print;
>  #define kexec_dprintk(fmt, arg...) \
>          do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
>  
> -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
> +extern void *kimage_map_segment(struct kimage *image, int idx);
>  extern void kimage_unmap_segment(void *buffer);
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
> @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
>  static inline void crash_kexec(struct pt_regs *regs) { }
>  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
>  static inline int kexec_crash_loaded(void) { return 0; }
> -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
> +static inline void *kimage_map_segment(struct kimage *image, int idx)
>  { return NULL; }
>  static inline void kimage_unmap_segment(void *buffer) { }
>  #define kexec_in_progress false
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index fa00b239c5d9..9a1966207041 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *image, int idx)
>  	return result;
>  }
>  
> -void *kimage_map_segment(struct kimage *image,
> -			 unsigned long addr, unsigned long size)
> +void *kimage_map_segment(struct kimage *image, int idx)
>  {
> +	unsigned long addr, size, eaddr;
>  	unsigned long src_page_addr, dest_page_addr = 0;
> -	unsigned long eaddr = addr + size;
>  	kimage_entry_t *ptr, entry;
>  	struct page **src_pages;
>  	unsigned int npages;
>  	void *vaddr = NULL;
>  	int i;
>  
> +	addr = image->segment[idx].mem;
> +	size = image->segment[idx].memsz;
> +	eaddr = addr + size;
> +
>  	/*
>  	 * Collect the source pages and map them in a contiguous VA range.
>  	 */
> diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> index 7362f68f2d8b..5beb69edd12f 100644
> --- a/security/integrity/ima/ima_kexec.c
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image)
>  	if (!image->ima_buffer_addr)
>  		return;
>  
> -	ima_kexec_buffer = kimage_map_segment(image,
> -					      image->ima_buffer_addr,
> -					      image->ima_buffer_size);
> +	ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index);
>  	if (!ima_kexec_buffer) {
>  		pr_err("Could not map measurements buffer.\n");
>  		return;
> -- 
> 2.49.0
> 

Re: [PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Baoquan He]

Hi,

On 11/26/25 at 09:10am, Baoquan He wrote:
> Hi Pingfan,
> 
> On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > The kexec segment index will be required to extract the corresponding
> > information for that segment in kimage_map_segment(). Additionally,
> > kexec_segment already holds the kexec relocation destination address and
> > size. Therefore, the prototype of kimage_map_segment() can be changed.
> 
> Because no cover letter, I just reply here.
> 
> I am testing code of (tag: next-20251125, next/master) on arm64 system.
> I saw your two patches are already in there. When I used kexec reboot
> as below, I still got the warning message during ima_kexec_post_load()
> invocation. 

And when I try to turn off cma allocating for kexec buffer, I found
there's no such flag in user space utility kexec-tools. Since Alexander
introduced commit 07d24902977e ("kexec: enable CMA based contiguous
allocation"), but haven't add flag KEXEC_FILE_NO_CMA to kexec-tools, and
Pingfan you are working to fix the bug, can any of you post patch to
kexec-tools to add the flag?

And flag KEXEC_FILE_FORCE_DTB too, which was introduced in commit f367474b5884
("x86/kexec: carry forward the boot DTB on kexec").

We only have them in kernel, but there's no chance to specify them,
what's the meaning to have them?

Thanks
Baoquan

> 
> ====================
> kexec -d -l /boot/vmlinuz-6.18.0-rc7-next-20251125 --initrd /boot/initramfs-6.18.0-rc7-next-20251125.img --reuse-cmdline
> ====================
> 
> ====================
> [34283.657670] kexec_file: kernel: 000000006cf71829 kernel_size: 0x48b0000
> [34283.657700] PEFILE: Unsigned PE binary
> [34283.676597] ima: kexec measurement buffer for the loaded kernel at 0xff206000.
> [34283.676621] kexec_file: Loaded initrd at 0x84cb0000 bufsz=0x25ec426 memsz=0x25ed000
> [34283.684646] kexec_file: Loaded dtb at 0xff400000 bufsz=0x39e memsz=0x1000
> [34283.684653] kexec_file(Image): Loaded kernel at 0x80400000 bufsz=0x48b0000 memsz=0x48b0000
> [34283.684663] kexec_file: nr_segments = 4
> [34283.684666] kexec_file: segment[0]: buf=0x0000000000000000 bufsz=0x0 mem=0xff206000 memsz=0x1000
> [34283.684674] kexec_file: segment[1]: buf=0x000000006cf71829 bufsz=0x48b0000 mem=0x80400000 memsz=0x48b0000
> [34283.725987] kexec_file: segment[2]: buf=0x00000000c7369de6 bufsz=0x25ec426 mem=0x84cb0000 memsz=0x25ed000
> [34283.747670] kexec_file: segmen
> ** replaying previous printk message **
> [34283.747670] kexec_file: segment[3]: buf=0x00000000d83b530b bufsz=0x39e mem=0xff400000 memsz=0x1000
> [34283.747973] ------------[ cut here ]------------
> [34283.747976] WARNING: CPU: 33 PID: 16112 at kernel/kexec_core.c:1002 kimage_map_segment+0x138/0x190
> [34283.778574] Modules linked in: rfkill vfat fat ipmi_ssif igb acpi_ipmi ipmi_si ipmi_devintf mlx5_fwctl i2c_algo_bit ipmi_msghandler fwctl fuse loop nfnetlink zram lz4hc_compress lz4_compress xfs mlx5_ib macsec mlx5_core nvme nvme_core mlxfw psample tls nvme_keyring nvme_auth pci_hyperv_intf sbsa_gwdt rpcrdma sunrpc rdma_ucm ib_uverbs ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser i2c_dev ib_umad rdma_cm ib_ipoib iw_cm ib_cm libiscsi ib_core scsi_transport_iscsi aes_neon_bs
> [34283.824233] CPU: 33 UID: 0 PID: 16112 Comm: kexec Tainted: G        W           6.17.8-200.fc42.aarch64 #1 PREEMPT(voluntary) 
> [34283.836355] Tainted: [W]=WARN
> [34283.839684] Hardware name: CRAY CS500/CMUD        , BIOS 1.4.0 Jun 17 2020
> [34283.846903] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [34283.854243] pc : kimage_map_segment+0x138/0x190
> [34283.859120] lr : kimage_map_segment+0x4c/0x190
> [34283.863920] sp : ffff8000a0643a90
> [34283.867394] x29: ffff8000a0643a90 x28: ffff800083d0a000 x27: 0000000000000000
> [34283.874901] x26: 0000aaaad722d4b0 x25: 000000000000008f x24: ffff800083d0a000
> [34283.882608] x23: 0000000000000001 x22: 00000000ff206000 x21: 00000000ff207000
> [34283.890305] x20: ffff008fbd306980 x19: ffff008f895d6400 x18: 00000000fffffff9
> [34283.897815] x17: 303d6d656d206539 x16: 3378303d7a736675 x15: 646565732d676e72
> [34283.905516] x14: 00646565732d726c x13: 616d692c78756e69 x12: 6c00636578656b2d
> [34283.912999] x11: 007265666675622d x10: 636578656b2d616d x9 : ffff80008050b73c
> [34283.920691] x8 : 0001000000000000 x7 : 0000000000000000 x6 : 0000000080000000
> [34283.928197] x5 : 0000000084cb0000 x4 : ffff008fbd2306b0 x3 : ffff008fbd305000
> [34283.935898] x2 : fffffff7ff000000 x1 : 0000000000000004 x0 : ffff800082046000
> [34283.943603] Call trace:
> [34283.946039]  kimage_map_segment+0x138/0x190 (P)
> [34283.950935]  ima_kexec_post_load+0x58/0xc0
> [34283.955225]  __do_sys_kexec_file_load+0x2b8/0x398
> [34283.960279]  __arm64_sys_kexec_file_load+0x28/0x40
> [34283.965965]  invoke_syscall.constprop.0+0x64/0xe8
> [34283.971025]  el0_svc_common.constprop.0+0x40/0xe8
> [34283.975883]  do_el0_svc+0x24/0x38
> [34283.979361]  el0_svc+0x3c/0x168
> [34283.982833]  el0t_64_sync_handler+0xa0/0xf0
> [34283.987176]  el0t_64_sync+0x1b0/0x1b8
> [34283.991000] ---[ end trace 0000000000000000 ]---
> [34283.996060] ------------[ cut here ]------------
> [34283.996064] WARNING: CPU: 33 PID: 16112 at mm/vmalloc.c:538 vmap_pages_pte_range+0x2bc/0x3c0
> [34284.010006] Modules linked in: rfkill vfat fat ipmi_ssif igb acpi_ipmi ipmi_si ipmi_devintf mlx5_fwctl i2c_algo_bit ipmi_msghandler fwctl fuse loop nfnetlink zram lz4hc_compress lz4_compress xfs mlx5_ib macsec mlx5_core nvme nvme_core mlxfw psample tls nvme_keyring nvme_auth pci_hyperv_intf sbsa_gwdt rpcrdma sunrpc rdma_ucm ib_uverbs ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser i2c_dev ib_umad rdma_cm ib_ipoib iw_cm ib_cm libiscsi ib_core scsi_transport_iscsi aes_neon_bs
> [34284.055630] CPU: 33 UID: 0 PID: 16112 Comm: kexec Tainted: G        W           6.17.8-200.fc42.aarch64 #1 PREEMPT(voluntary) 
> [34284.067701] Tainted: [W]=WARN
> [34284.070833] Hardware name: CRAY CS500/CMUD        , BIOS 1.4.0 Jun 17 2020
> [34284.078238] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [34284.085546] pc : vmap_pages_pte_range+0x2bc/0x3c0
> [34284.090607] lr : vmap_small_pages_range_noflush+0x16c/0x298
> [34284.096528] sp : ffff8000a0643940
> [34284.100001] x29: ffff8000a0643940 x28: 0000000000000000 x27: ffff800084f76000
> [34284.107699] x26: fffffdffc0000000 x25: ffff8000a06439d0 x24: ffff800082046000
> [34284.115174] x23: ffff800084f75000 x22: ffff007f80337ba8 x21: 03ffffffffffffc0
> [34284.122821] x20: ffff008fbd306980 x19: ffff8000a06439d4 x18: 00000000fffffff9
> [34284.130331] x17: 303d6d656d206539 x16: 3378303d7a736675 x15: 646565732d676e72
> [34284.138032] x14: 0000000000004000 x13: ffff009781307130 x12: 0000000000002000
> [34284.145733] x11: 0000000000000000 x10: 0000000000000001 x9 : ffff8000804e197c
> [34284.153248] x8 : 0000000000000027 x7 : ffff800085175000 x6 : ffff8000a06439d4
> [34284.160944] x5 : ffff8000a06439d0 x4 : ffff008fbd306980 x3 : 0068000000000f03
> [34284.168449] x2 : ffff007f80337ba8 x1 : 0000000000000000 x0 : 0000000000000000
> [34284.176150] Call trace:
> [34284.178768]  vmap_pages_pte_range+0x2bc/0x3c0 (P)
> [34284.183665]  vmap_small_pages_range_noflush+0x16c/0x298
> [34284.189264]  vmap+0xb4/0x138
> [34284.192312]  kimage_map_segment+0xdc/0x190
> [34284.196794]  ima_kexec_post_load+0x58/0xc0
> [34284.201044]  __do_sys_kexec_file_load+0x2b8/0x398
> [34284.206107]  __arm64_sys_kexec_file_load+0x28/0x40
> [34284.211254]  invoke_syscall.constprop.0+0x64/0xe8
> [34284.216139]  el0_svc_common.constprop.0+0x40/0xe8
> [34284.221196]  do_el0_svc+0x24/0x38
> [34284.224678]  el0_svc+0x3c/0x168
> [34284.227983]  el0t_64_sync_handler+0xa0/0xf0
> [34284.232526]  el0t_64_sync+0x1b0/0x1b8
> [34284.236376] ---[ end trace 0000000000000000 ]---
> [34284.241412] kexec_core: Could not map ima buffer.
> [34284.241421] ima: Could not map measurements buffer.
> [34284.551336] machine_kexec_post_load:155:
> [34284.551354]   kexec kimage info:
> [34284.551366]     type:        0
> [34284.551373]     head:        90363f9002
> [34284.551377]     kern_reloc: 0x00000090363f7000
> [34284.551381]     el2_vectors: 0x0000000000000000
> [34284.551384] kexec_file: kexec_file_load: type:0, start:0x80400000 head:0x90363f9002 flags:0x8
> ====================
> 
> > 
> > Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> > Signed-off-by: Pingfan Liu <piliu@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Baoquan He <bhe@redhat.com>
> > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > Cc: Roberto Sassu <roberto.sassu@huawei.com>
> > Cc: Alexander Graf <graf@amazon.com>
> > Cc: Steven Chen <chenste@linux.microsoft.com>
> > Cc: <stable@vger.kernel.org>
> > To: kexec@lists.infradead.org
> > To: linux-integrity@vger.kernel.org
> > ---
> >  include/linux/kexec.h              | 4 ++--
> >  kernel/kexec_core.c                | 9 ++++++---
> >  security/integrity/ima/ima_kexec.c | 4 +---
> >  3 files changed, 9 insertions(+), 8 deletions(-)
> > 
> > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > index ff7e231b0485..8a22bc9b8c6c 100644
> > --- a/include/linux/kexec.h
> > +++ b/include/linux/kexec.h
> > @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print;
> >  #define kexec_dprintk(fmt, arg...) \
> >          do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
> >  
> > -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
> > +extern void *kimage_map_segment(struct kimage *image, int idx);
> >  extern void kimage_unmap_segment(void *buffer);
> >  #else /* !CONFIG_KEXEC_CORE */
> >  struct pt_regs;
> > @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
> >  static inline void crash_kexec(struct pt_regs *regs) { }
> >  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
> >  static inline int kexec_crash_loaded(void) { return 0; }
> > -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
> > +static inline void *kimage_map_segment(struct kimage *image, int idx)
> >  { return NULL; }
> >  static inline void kimage_unmap_segment(void *buffer) { }
> >  #define kexec_in_progress false
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index fa00b239c5d9..9a1966207041 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *image, int idx)
> >  	return result;
> >  }
> >  
> > -void *kimage_map_segment(struct kimage *image,
> > -			 unsigned long addr, unsigned long size)
> > +void *kimage_map_segment(struct kimage *image, int idx)
> >  {
> > +	unsigned long addr, size, eaddr;
> >  	unsigned long src_page_addr, dest_page_addr = 0;
> > -	unsigned long eaddr = addr + size;
> >  	kimage_entry_t *ptr, entry;
> >  	struct page **src_pages;
> >  	unsigned int npages;
> >  	void *vaddr = NULL;
> >  	int i;
> >  
> > +	addr = image->segment[idx].mem;
> > +	size = image->segment[idx].memsz;
> > +	eaddr = addr + size;
> > +
> >  	/*
> >  	 * Collect the source pages and map them in a contiguous VA range.
> >  	 */
> > diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> > index 7362f68f2d8b..5beb69edd12f 100644
> > --- a/security/integrity/ima/ima_kexec.c
> > +++ b/security/integrity/ima/ima_kexec.c
> > @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image)
> >  	if (!image->ima_buffer_addr)
> >  		return;
> >  
> > -	ima_kexec_buffer = kimage_map_segment(image,
> > -					      image->ima_buffer_addr,
> > -					      image->ima_buffer_size);
> > +	ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index);
> >  	if (!ima_kexec_buffer) {
> >  		pr_err("Could not map measurements buffer.\n");
> >  		return;
> > -- 
> > 2.49.0
> > 
> 

Re: [PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Pingfan Liu]

On Wed, Nov 26, 2025 at 9:54 AM Baoquan He <bhe@redhat.com> wrote:
>
> Hi,
>
> On 11/26/25 at 09:10am, Baoquan He wrote:
> > Hi Pingfan,
> >
> > On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > > The kexec segment index will be required to extract the corresponding
> > > information for that segment in kimage_map_segment(). Additionally,
> > > kexec_segment already holds the kexec relocation destination address and
> > > size. Therefore, the prototype of kimage_map_segment() can be changed.
> >
> > Because no cover letter, I just reply here.
> >
> > I am testing code of (tag: next-20251125, next/master) on arm64 system.
> > I saw your two patches are already in there. When I used kexec reboot
> > as below, I still got the warning message during ima_kexec_post_load()
> > invocation.
>

I ran into this warning on the platform "NVIDIA Jetson Orin Nano". I
just got the control of this machine and have an opportunity to decode
its dtb.

I think the following section is critical to reproduce this issue

        reserved-memory {
                #address-cells = <0x02>;
                #size-cells = <0x02>;
                ranges;

                linux,cma {
                        linux,cma-default;
                        alignment = <0x00 0x10000>;
                        compatible = "shared-dma-pool";
                        size = <0x00 0x10000000>;
                        status = "okay";
                        reusable;
                };

That is weird. I used (tag: next-20251125, next/master) to have a
test, and  cann't see the warning any longer.

Once you finish with the machine, I'll run some tests to check if the
warning comes from the same root cause on your machine.

> And when I try to turn off cma allocating for kexec buffer, I found
> there's no such flag in user space utility kexec-tools. Since Alexander
> introduced commit 07d24902977e ("kexec: enable CMA based contiguous
> allocation"), but haven't add flag KEXEC_FILE_NO_CMA to kexec-tools, and
> Pingfan you are working to fix the bug, can any of you post patch to
> kexec-tools to add the flag?
>

OK.

> And flag KEXEC_FILE_FORCE_DTB too, which was introduced in commit f367474b5884
> ("x86/kexec: carry forward the boot DTB on kexec").
>

I have no idea about KEXEC_FILE_FORCE_DTB for the time being. But I
will see how to handle it properer.

Thanks,

Pingfan

> We only have them in kernel, but there's no chance to specify them,
> what's the meaning to have them?
>
> Thanks
> Baoquan
>
> >
> > ====================
> > kexec -d -l /boot/vmlinuz-6.18.0-rc7-next-20251125 --initrd /boot/initramfs-6.18.0-rc7-next-20251125.img --reuse-cmdline
> > ====================
> >
> > ====================
> > [34283.657670] kexec_file: kernel: 000000006cf71829 kernel_size: 0x48b0000
> > [34283.657700] PEFILE: Unsigned PE binary
> > [34283.676597] ima: kexec measurement buffer for the loaded kernel at 0xff206000.
> > [34283.676621] kexec_file: Loaded initrd at 0x84cb0000 bufsz=0x25ec426 memsz=0x25ed000
> > [34283.684646] kexec_file: Loaded dtb at 0xff400000 bufsz=0x39e memsz=0x1000
> > [34283.684653] kexec_file(Image): Loaded kernel at 0x80400000 bufsz=0x48b0000 memsz=0x48b0000
> > [34283.684663] kexec_file: nr_segments = 4
> > [34283.684666] kexec_file: segment[0]: buf=0x0000000000000000 bufsz=0x0 mem=0xff206000 memsz=0x1000
> > [34283.684674] kexec_file: segment[1]: buf=0x000000006cf71829 bufsz=0x48b0000 mem=0x80400000 memsz=0x48b0000
> > [34283.725987] kexec_file: segment[2]: buf=0x00000000c7369de6 bufsz=0x25ec426 mem=0x84cb0000 memsz=0x25ed000
> > [34283.747670] kexec_file: segmen
> > ** replaying previous printk message **
> > [34283.747670] kexec_file: segment[3]: buf=0x00000000d83b530b bufsz=0x39e mem=0xff400000 memsz=0x1000
> > [34283.747973] ------------[ cut here ]------------
> > [34283.747976] WARNING: CPU: 33 PID: 16112 at kernel/kexec_core.c:1002 kimage_map_segment+0x138/0x190
> > [34283.778574] Modules linked in: rfkill vfat fat ipmi_ssif igb acpi_ipmi ipmi_si ipmi_devintf mlx5_fwctl i2c_algo_bit ipmi_msghandler fwctl fuse loop nfnetlink zram lz4hc_compress lz4_compress xfs mlx5_ib macsec mlx5_core nvme nvme_core mlxfw psample tls nvme_keyring nvme_auth pci_hyperv_intf sbsa_gwdt rpcrdma sunrpc rdma_ucm ib_uverbs ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser i2c_dev ib_umad rdma_cm ib_ipoib iw_cm ib_cm libiscsi ib_core scsi_transport_iscsi aes_neon_bs
> > [34283.824233] CPU: 33 UID: 0 PID: 16112 Comm: kexec Tainted: G        W           6.17.8-200.fc42.aarch64 #1 PREEMPT(voluntary)
> > [34283.836355] Tainted: [W]=WARN
> > [34283.839684] Hardware name: CRAY CS500/CMUD        , BIOS 1.4.0 Jun 17 2020
> > [34283.846903] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [34283.854243] pc : kimage_map_segment+0x138/0x190
> > [34283.859120] lr : kimage_map_segment+0x4c/0x190
> > [34283.863920] sp : ffff8000a0643a90
> > [34283.867394] x29: ffff8000a0643a90 x28: ffff800083d0a000 x27: 0000000000000000
> > [34283.874901] x26: 0000aaaad722d4b0 x25: 000000000000008f x24: ffff800083d0a000
> > [34283.882608] x23: 0000000000000001 x22: 00000000ff206000 x21: 00000000ff207000
> > [34283.890305] x20: ffff008fbd306980 x19: ffff008f895d6400 x18: 00000000fffffff9
> > [34283.897815] x17: 303d6d656d206539 x16: 3378303d7a736675 x15: 646565732d676e72
> > [34283.905516] x14: 00646565732d726c x13: 616d692c78756e69 x12: 6c00636578656b2d
> > [34283.912999] x11: 007265666675622d x10: 636578656b2d616d x9 : ffff80008050b73c
> > [34283.920691] x8 : 0001000000000000 x7 : 0000000000000000 x6 : 0000000080000000
> > [34283.928197] x5 : 0000000084cb0000 x4 : ffff008fbd2306b0 x3 : ffff008fbd305000
> > [34283.935898] x2 : fffffff7ff000000 x1 : 0000000000000004 x0 : ffff800082046000
> > [34283.943603] Call trace:
> > [34283.946039]  kimage_map_segment+0x138/0x190 (P)
> > [34283.950935]  ima_kexec_post_load+0x58/0xc0
> > [34283.955225]  __do_sys_kexec_file_load+0x2b8/0x398
> > [34283.960279]  __arm64_sys_kexec_file_load+0x28/0x40
> > [34283.965965]  invoke_syscall.constprop.0+0x64/0xe8
> > [34283.971025]  el0_svc_common.constprop.0+0x40/0xe8
> > [34283.975883]  do_el0_svc+0x24/0x38
> > [34283.979361]  el0_svc+0x3c/0x168
> > [34283.982833]  el0t_64_sync_handler+0xa0/0xf0
> > [34283.987176]  el0t_64_sync+0x1b0/0x1b8
> > [34283.991000] ---[ end trace 0000000000000000 ]---
> > [34283.996060] ------------[ cut here ]------------
> > [34283.996064] WARNING: CPU: 33 PID: 16112 at mm/vmalloc.c:538 vmap_pages_pte_range+0x2bc/0x3c0
> > [34284.010006] Modules linked in: rfkill vfat fat ipmi_ssif igb acpi_ipmi ipmi_si ipmi_devintf mlx5_fwctl i2c_algo_bit ipmi_msghandler fwctl fuse loop nfnetlink zram lz4hc_compress lz4_compress xfs mlx5_ib macsec mlx5_core nvme nvme_core mlxfw psample tls nvme_keyring nvme_auth pci_hyperv_intf sbsa_gwdt rpcrdma sunrpc rdma_ucm ib_uverbs ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser i2c_dev ib_umad rdma_cm ib_ipoib iw_cm ib_cm libiscsi ib_core scsi_transport_iscsi aes_neon_bs
> > [34284.055630] CPU: 33 UID: 0 PID: 16112 Comm: kexec Tainted: G        W           6.17.8-200.fc42.aarch64 #1 PREEMPT(voluntary)
> > [34284.067701] Tainted: [W]=WARN
> > [34284.070833] Hardware name: CRAY CS500/CMUD        , BIOS 1.4.0 Jun 17 2020
> > [34284.078238] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [34284.085546] pc : vmap_pages_pte_range+0x2bc/0x3c0
> > [34284.090607] lr : vmap_small_pages_range_noflush+0x16c/0x298
> > [34284.096528] sp : ffff8000a0643940
> > [34284.100001] x29: ffff8000a0643940 x28: 0000000000000000 x27: ffff800084f76000
> > [34284.107699] x26: fffffdffc0000000 x25: ffff8000a06439d0 x24: ffff800082046000
> > [34284.115174] x23: ffff800084f75000 x22: ffff007f80337ba8 x21: 03ffffffffffffc0
> > [34284.122821] x20: ffff008fbd306980 x19: ffff8000a06439d4 x18: 00000000fffffff9
> > [34284.130331] x17: 303d6d656d206539 x16: 3378303d7a736675 x15: 646565732d676e72
> > [34284.138032] x14: 0000000000004000 x13: ffff009781307130 x12: 0000000000002000
> > [34284.145733] x11: 0000000000000000 x10: 0000000000000001 x9 : ffff8000804e197c
> > [34284.153248] x8 : 0000000000000027 x7 : ffff800085175000 x6 : ffff8000a06439d4
> > [34284.160944] x5 : ffff8000a06439d0 x4 : ffff008fbd306980 x3 : 0068000000000f03
> > [34284.168449] x2 : ffff007f80337ba8 x1 : 0000000000000000 x0 : 0000000000000000
> > [34284.176150] Call trace:
> > [34284.178768]  vmap_pages_pte_range+0x2bc/0x3c0 (P)
> > [34284.183665]  vmap_small_pages_range_noflush+0x16c/0x298
> > [34284.189264]  vmap+0xb4/0x138
> > [34284.192312]  kimage_map_segment+0xdc/0x190
> > [34284.196794]  ima_kexec_post_load+0x58/0xc0
> > [34284.201044]  __do_sys_kexec_file_load+0x2b8/0x398
> > [34284.206107]  __arm64_sys_kexec_file_load+0x28/0x40
> > [34284.211254]  invoke_syscall.constprop.0+0x64/0xe8
> > [34284.216139]  el0_svc_common.constprop.0+0x40/0xe8
> > [34284.221196]  do_el0_svc+0x24/0x38
> > [34284.224678]  el0_svc+0x3c/0x168
> > [34284.227983]  el0t_64_sync_handler+0xa0/0xf0
> > [34284.232526]  el0t_64_sync+0x1b0/0x1b8
> > [34284.236376] ---[ end trace 0000000000000000 ]---
> > [34284.241412] kexec_core: Could not map ima buffer.
> > [34284.241421] ima: Could not map measurements buffer.
> > [34284.551336] machine_kexec_post_load:155:
> > [34284.551354]   kexec kimage info:
> > [34284.551366]     type:        0
> > [34284.551373]     head:        90363f9002
> > [34284.551377]     kern_reloc: 0x00000090363f7000
> > [34284.551381]     el2_vectors: 0x0000000000000000
> > [34284.551384] kexec_file: kexec_file_load: type:0, start:0x80400000 head:0x90363f9002 flags:0x8
> > ====================
> >
> > >
> > > Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> > > Signed-off-by: Pingfan Liu <piliu@redhat.com>
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > Cc: Baoquan He <bhe@redhat.com>
> > > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > > Cc: Roberto Sassu <roberto.sassu@huawei.com>
> > > Cc: Alexander Graf <graf@amazon.com>
> > > Cc: Steven Chen <chenste@linux.microsoft.com>
> > > Cc: <stable@vger.kernel.org>
> > > To: kexec@lists.infradead.org
> > > To: linux-integrity@vger.kernel.org
> > > ---
> > >  include/linux/kexec.h              | 4 ++--
> > >  kernel/kexec_core.c                | 9 ++++++---
> > >  security/integrity/ima/ima_kexec.c | 4 +---
> > >  3 files changed, 9 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > > index ff7e231b0485..8a22bc9b8c6c 100644
> > > --- a/include/linux/kexec.h
> > > +++ b/include/linux/kexec.h
> > > @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print;
> > >  #define kexec_dprintk(fmt, arg...) \
> > >          do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
> > >
> > > -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
> > > +extern void *kimage_map_segment(struct kimage *image, int idx);
> > >  extern void kimage_unmap_segment(void *buffer);
> > >  #else /* !CONFIG_KEXEC_CORE */
> > >  struct pt_regs;
> > > @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
> > >  static inline void crash_kexec(struct pt_regs *regs) { }
> > >  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
> > >  static inline int kexec_crash_loaded(void) { return 0; }
> > > -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
> > > +static inline void *kimage_map_segment(struct kimage *image, int idx)
> > >  { return NULL; }
> > >  static inline void kimage_unmap_segment(void *buffer) { }
> > >  #define kexec_in_progress false
> > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > > index fa00b239c5d9..9a1966207041 100644
> > > --- a/kernel/kexec_core.c
> > > +++ b/kernel/kexec_core.c
> > > @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *image, int idx)
> > >     return result;
> > >  }
> > >
> > > -void *kimage_map_segment(struct kimage *image,
> > > -                    unsigned long addr, unsigned long size)
> > > +void *kimage_map_segment(struct kimage *image, int idx)
> > >  {
> > > +   unsigned long addr, size, eaddr;
> > >     unsigned long src_page_addr, dest_page_addr = 0;
> > > -   unsigned long eaddr = addr + size;
> > >     kimage_entry_t *ptr, entry;
> > >     struct page **src_pages;
> > >     unsigned int npages;
> > >     void *vaddr = NULL;
> > >     int i;
> > >
> > > +   addr = image->segment[idx].mem;
> > > +   size = image->segment[idx].memsz;
> > > +   eaddr = addr + size;
> > > +
> > >     /*
> > >      * Collect the source pages and map them in a contiguous VA range.
> > >      */
> > > diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> > > index 7362f68f2d8b..5beb69edd12f 100644
> > > --- a/security/integrity/ima/ima_kexec.c
> > > +++ b/security/integrity/ima/ima_kexec.c
> > > @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image)
> > >     if (!image->ima_buffer_addr)
> > >             return;
> > >
> > > -   ima_kexec_buffer = kimage_map_segment(image,
> > > -                                         image->ima_buffer_addr,
> > > -                                         image->ima_buffer_size);
> > > +   ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index);
> > >     if (!ima_kexec_buffer) {
> > >             pr_err("Could not map measurements buffer.\n");
> > >             return;
> > > --
> > > 2.49.0
> > >
> >
>

Re: [PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Pingfan Liu]

On Wed, Nov 26, 2025 at 9:10 AM Baoquan He <bhe@redhat.com> wrote:
>
> Hi Pingfan,
>
> On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > The kexec segment index will be required to extract the corresponding
> > information for that segment in kimage_map_segment(). Additionally,
> > kexec_segment already holds the kexec relocation destination address and
> > size. Therefore, the prototype of kimage_map_segment() can be changed.
>
> Because no cover letter, I just reply here.
>
> I am testing code of (tag: next-20251125, next/master) on arm64 system.
> I saw your two patches are already in there. When I used kexec reboot
> as below, I still got the warning message during ima_kexec_post_load()
> invocation.
>
> ====================
> kexec -d -l /boot/vmlinuz-6.18.0-rc7-next-20251125 --initrd /boot/initramfs-6.18.0-rc7-next-20251125.img --reuse-cmdline
> ====================
>

Could you share more detail, as I cannot reproduce this issue with
(tag: next-20251125, next/master) on a different aarch64 platform
either.
I use the default config to compile the kernel and add CMA=512M in the
kernel command line, so the kexec file load can allocate the dest
memory directly on the CMA area.

# lshw -class system
hpe-apollo***
    description: System
    product: CS500 (-)
    vendor: CRAY
    version: -
    serial: -
    width: 64 bits
    capabilities: smbios-3.1.1 dmi-3.1.1 smp sve_default_vector_length
tagged_addr_disabled
    configuration: boot=normal chassis=server family=HPC sku=-
uuid=8cdb9098-d03f-11e9-8001-2cd444ce8cad

#cat /proc/meminfo | grep -i cma
CmaTotal:         524288 kB
CmaFree:          509856 kB
# cd /boot/
# kexec -d -s -l vmlinuz-6.18.0-rc7-next-20251125 --initrd
initramfs-6.18.0-rc7-next-20251125.img --reuse-cmdline
arch_process_options:179: command_line:
root=/dev/mapper/rhel_hpe--apollo80--02--n00-root ro
earlycon=pl011,0x1c050000 ip=dhcp
crashkernel=2G-4G:406M,4G-64G:470M,64G-:726M
rd.lvm.lv=rhel_hpe-apollo80-02-n00/root
rd.lvm.lv=rhel_hpe-apollo80-02-n00/swap console=ttyAMA0  cma=512M
arch_process_options:181: initrd: initramfs-6.18.0-rc7-next-20251125.img
arch_process_options:183: dtb: (null)
arch_process_options:186: console: (null)
Try gzip decompression.
Try LZMA decompression.
elf_arm64_probe: Not an ELF executable.
image_arm64_probe: Bad arm64 image header.
pez_arm64_probe: PROBE.
Try gzip decompression.
pez_prepare: decompressed size 50790400
pez_prepare: done
# cat /proc/meminfo | grep -i cma
CmaTotal:         524288 kB
CmaFree:          411032 kB

CmaFree shrinks, which means the kexec_file_load uses it.

And the dmesg shows no warning
[  167.484064] kexec_file: kernel: 0000000096e14552 kernel_size: 0x3070000
[  167.484094] PEFILE: Unsigned PE binary
[  167.576003] ima: kexec measurement buffer for the loaded kernel at
0xc1a18000.
[  167.585054] kexec_file: Loaded initrd at 0xc4b70000 bufsz=0x300f306
memsz=0x3010000
[  167.593376] kexec_file: Loaded dtb at 0xc7c00000 bufsz=0x5b1 memsz=0x1000
[  167.593389] kexec_file(Image): Loaded kernel at 0xc1b00000
bufsz=0x3070000 memsz=0x3070000
[  167.593405] kexec_file: nr_segments = 4
[  167.593408] kexec_file: segment[0]: buf=0x0000000000000000
bufsz=0x0 mem=0xc1a18000 memsz=0x1000
[  167.593417] kexec_file: segment[1]: buf=0x0000000096e14552
bufsz=0x3070000 mem=0xc1b00000 memsz=0x3070000
[  167.610450] kexec_file: segment[2]: buf=0x000000001285672d
bufsz=0x300f306 mem=0xc4b70000 memsz=0x3010000
[  167.627563] kexec_file: segment[3]: buf=0x000000002ef3060d
bufsz=0x5b1 mem=0xc7c00000 memsz=0x1000
[  167.629228] machine_kexec_post_load:119:
[  167.629233]   kexec kimage info:
[  167.629236]     type:        0
[  167.629238]     head:        4
[  167.629241]     kern_reloc: 0x0000000000000000
[  167.629245]     el2_vectors: 0x0000000000000000
[  167.629248] kexec_file: kexec_file_load: type:0, start:0xc1b00000
head:0x4 flags:0x8


Thanks,

Pingfan


> ====================
> [34283.657670] kexec_file: kernel: 000000006cf71829 kernel_size: 0x48b0000
> [34283.657700] PEFILE: Unsigned PE binary
> [34283.676597] ima: kexec measurement buffer for the loaded kernel at 0xff206000.
> [34283.676621] kexec_file: Loaded initrd at 0x84cb0000 bufsz=0x25ec426 memsz=0x25ed000
> [34283.684646] kexec_file: Loaded dtb at 0xff400000 bufsz=0x39e memsz=0x1000
> [34283.684653] kexec_file(Image): Loaded kernel at 0x80400000 bufsz=0x48b0000 memsz=0x48b0000
> [34283.684663] kexec_file: nr_segments = 4
> [34283.684666] kexec_file: segment[0]: buf=0x0000000000000000 bufsz=0x0 mem=0xff206000 memsz=0x1000
> [34283.684674] kexec_file: segment[1]: buf=0x000000006cf71829 bufsz=0x48b0000 mem=0x80400000 memsz=0x48b0000
> [34283.725987] kexec_file: segment[2]: buf=0x00000000c7369de6 bufsz=0x25ec426 mem=0x84cb0000 memsz=0x25ed000
> [34283.747670] kexec_file: segmen
> ** replaying previous printk message **
> [34283.747670] kexec_file: segment[3]: buf=0x00000000d83b530b bufsz=0x39e mem=0xff400000 memsz=0x1000
> [34283.747973] ------------[ cut here ]------------
> [34283.747976] WARNING: CPU: 33 PID: 16112 at kernel/kexec_core.c:1002 kimage_map_segment+0x138/0x190
> [34283.778574] Modules linked in: rfkill vfat fat ipmi_ssif igb acpi_ipmi ipmi_si ipmi_devintf mlx5_fwctl i2c_algo_bit ipmi_msghandler fwctl fuse loop nfnetlink zram lz4hc_compress lz4_compress xfs mlx5_ib macsec mlx5_core nvme nvme_core mlxfw psample tls nvme_keyring nvme_auth pci_hyperv_intf sbsa_gwdt rpcrdma sunrpc rdma_ucm ib_uverbs ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser i2c_dev ib_umad rdma_cm ib_ipoib iw_cm ib_cm libiscsi ib_core scsi_transport_iscsi aes_neon_bs
> [34283.824233] CPU: 33 UID: 0 PID: 16112 Comm: kexec Tainted: G        W           6.17.8-200.fc42.aarch64 #1 PREEMPT(voluntary)
> [34283.836355] Tainted: [W]=WARN
> [34283.839684] Hardware name: CRAY CS500/CMUD        , BIOS 1.4.0 Jun 17 2020
> [34283.846903] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [34283.854243] pc : kimage_map_segment+0x138/0x190
> [34283.859120] lr : kimage_map_segment+0x4c/0x190
> [34283.863920] sp : ffff8000a0643a90
> [34283.867394] x29: ffff8000a0643a90 x28: ffff800083d0a000 x27: 0000000000000000
> [34283.874901] x26: 0000aaaad722d4b0 x25: 000000000000008f x24: ffff800083d0a000
> [34283.882608] x23: 0000000000000001 x22: 00000000ff206000 x21: 00000000ff207000
> [34283.890305] x20: ffff008fbd306980 x19: ffff008f895d6400 x18: 00000000fffffff9
> [34283.897815] x17: 303d6d656d206539 x16: 3378303d7a736675 x15: 646565732d676e72
> [34283.905516] x14: 00646565732d726c x13: 616d692c78756e69 x12: 6c00636578656b2d
> [34283.912999] x11: 007265666675622d x10: 636578656b2d616d x9 : ffff80008050b73c
> [34283.920691] x8 : 0001000000000000 x7 : 0000000000000000 x6 : 0000000080000000
> [34283.928197] x5 : 0000000084cb0000 x4 : ffff008fbd2306b0 x3 : ffff008fbd305000
> [34283.935898] x2 : fffffff7ff000000 x1 : 0000000000000004 x0 : ffff800082046000
> [34283.943603] Call trace:
> [34283.946039]  kimage_map_segment+0x138/0x190 (P)
> [34283.950935]  ima_kexec_post_load+0x58/0xc0
> [34283.955225]  __do_sys_kexec_file_load+0x2b8/0x398
> [34283.960279]  __arm64_sys_kexec_file_load+0x28/0x40
> [34283.965965]  invoke_syscall.constprop.0+0x64/0xe8
> [34283.971025]  el0_svc_common.constprop.0+0x40/0xe8
> [34283.975883]  do_el0_svc+0x24/0x38
> [34283.979361]  el0_svc+0x3c/0x168
> [34283.982833]  el0t_64_sync_handler+0xa0/0xf0
> [34283.987176]  el0t_64_sync+0x1b0/0x1b8
> [34283.991000] ---[ end trace 0000000000000000 ]---
> [34283.996060] ------------[ cut here ]------------
> [34283.996064] WARNING: CPU: 33 PID: 16112 at mm/vmalloc.c:538 vmap_pages_pte_range+0x2bc/0x3c0
> [34284.010006] Modules linked in: rfkill vfat fat ipmi_ssif igb acpi_ipmi ipmi_si ipmi_devintf mlx5_fwctl i2c_algo_bit ipmi_msghandler fwctl fuse loop nfnetlink zram lz4hc_compress lz4_compress xfs mlx5_ib macsec mlx5_core nvme nvme_core mlxfw psample tls nvme_keyring nvme_auth pci_hyperv_intf sbsa_gwdt rpcrdma sunrpc rdma_ucm ib_uverbs ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser i2c_dev ib_umad rdma_cm ib_ipoib iw_cm ib_cm libiscsi ib_core scsi_transport_iscsi aes_neon_bs
> [34284.055630] CPU: 33 UID: 0 PID: 16112 Comm: kexec Tainted: G        W           6.17.8-200.fc42.aarch64 #1 PREEMPT(voluntary)
> [34284.067701] Tainted: [W]=WARN
> [34284.070833] Hardware name: CRAY CS500/CMUD        , BIOS 1.4.0 Jun 17 2020
> [34284.078238] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [34284.085546] pc : vmap_pages_pte_range+0x2bc/0x3c0
> [34284.090607] lr : vmap_small_pages_range_noflush+0x16c/0x298
> [34284.096528] sp : ffff8000a0643940
> [34284.100001] x29: ffff8000a0643940 x28: 0000000000000000 x27: ffff800084f76000
> [34284.107699] x26: fffffdffc0000000 x25: ffff8000a06439d0 x24: ffff800082046000
> [34284.115174] x23: ffff800084f75000 x22: ffff007f80337ba8 x21: 03ffffffffffffc0
> [34284.122821] x20: ffff008fbd306980 x19: ffff8000a06439d4 x18: 00000000fffffff9
> [34284.130331] x17: 303d6d656d206539 x16: 3378303d7a736675 x15: 646565732d676e72
> [34284.138032] x14: 0000000000004000 x13: ffff009781307130 x12: 0000000000002000
> [34284.145733] x11: 0000000000000000 x10: 0000000000000001 x9 : ffff8000804e197c
> [34284.153248] x8 : 0000000000000027 x7 : ffff800085175000 x6 : ffff8000a06439d4
> [34284.160944] x5 : ffff8000a06439d0 x4 : ffff008fbd306980 x3 : 0068000000000f03
> [34284.168449] x2 : ffff007f80337ba8 x1 : 0000000000000000 x0 : 0000000000000000
> [34284.176150] Call trace:
> [34284.178768]  vmap_pages_pte_range+0x2bc/0x3c0 (P)
> [34284.183665]  vmap_small_pages_range_noflush+0x16c/0x298
> [34284.189264]  vmap+0xb4/0x138
> [34284.192312]  kimage_map_segment+0xdc/0x190
> [34284.196794]  ima_kexec_post_load+0x58/0xc0
> [34284.201044]  __do_sys_kexec_file_load+0x2b8/0x398
> [34284.206107]  __arm64_sys_kexec_file_load+0x28/0x40
> [34284.211254]  invoke_syscall.constprop.0+0x64/0xe8
> [34284.216139]  el0_svc_common.constprop.0+0x40/0xe8
> [34284.221196]  do_el0_svc+0x24/0x38
> [34284.224678]  el0_svc+0x3c/0x168
> [34284.227983]  el0t_64_sync_handler+0xa0/0xf0
> [34284.232526]  el0t_64_sync+0x1b0/0x1b8
> [34284.236376] ---[ end trace 0000000000000000 ]---
> [34284.241412] kexec_core: Could not map ima buffer.
> [34284.241421] ima: Could not map measurements buffer.
> [34284.551336] machine_kexec_post_load:155:
> [34284.551354]   kexec kimage info:
> [34284.551366]     type:        0
> [34284.551373]     head:        90363f9002
> [34284.551377]     kern_reloc: 0x00000090363f7000
> [34284.551381]     el2_vectors: 0x0000000000000000
> [34284.551384] kexec_file: kexec_file_load: type:0, start:0x80400000 head:0x90363f9002 flags:0x8
> ====================
>
> >
> > Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> > Signed-off-by: Pingfan Liu <piliu@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Baoquan He <bhe@redhat.com>
> > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > Cc: Roberto Sassu <roberto.sassu@huawei.com>
> > Cc: Alexander Graf <graf@amazon.com>
> > Cc: Steven Chen <chenste@linux.microsoft.com>
> > Cc: <stable@vger.kernel.org>
> > To: kexec@lists.infradead.org
> > To: linux-integrity@vger.kernel.org
> > ---
> >  include/linux/kexec.h              | 4 ++--
> >  kernel/kexec_core.c                | 9 ++++++---
> >  security/integrity/ima/ima_kexec.c | 4 +---
> >  3 files changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > index ff7e231b0485..8a22bc9b8c6c 100644
> > --- a/include/linux/kexec.h
> > +++ b/include/linux/kexec.h
> > @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print;
> >  #define kexec_dprintk(fmt, arg...) \
> >          do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
> >
> > -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
> > +extern void *kimage_map_segment(struct kimage *image, int idx);
> >  extern void kimage_unmap_segment(void *buffer);
> >  #else /* !CONFIG_KEXEC_CORE */
> >  struct pt_regs;
> > @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
> >  static inline void crash_kexec(struct pt_regs *regs) { }
> >  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
> >  static inline int kexec_crash_loaded(void) { return 0; }
> > -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
> > +static inline void *kimage_map_segment(struct kimage *image, int idx)
> >  { return NULL; }
> >  static inline void kimage_unmap_segment(void *buffer) { }
> >  #define kexec_in_progress false
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index fa00b239c5d9..9a1966207041 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *image, int idx)
> >       return result;
> >  }
> >
> > -void *kimage_map_segment(struct kimage *image,
> > -                      unsigned long addr, unsigned long size)
> > +void *kimage_map_segment(struct kimage *image, int idx)
> >  {
> > +     unsigned long addr, size, eaddr;
> >       unsigned long src_page_addr, dest_page_addr = 0;
> > -     unsigned long eaddr = addr + size;
> >       kimage_entry_t *ptr, entry;
> >       struct page **src_pages;
> >       unsigned int npages;
> >       void *vaddr = NULL;
> >       int i;
> >
> > +     addr = image->segment[idx].mem;
> > +     size = image->segment[idx].memsz;
> > +     eaddr = addr + size;
> > +
> >       /*
> >        * Collect the source pages and map them in a contiguous VA range.
> >        */
> > diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> > index 7362f68f2d8b..5beb69edd12f 100644
> > --- a/security/integrity/ima/ima_kexec.c
> > +++ b/security/integrity/ima/ima_kexec.c
> > @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image)
> >       if (!image->ima_buffer_addr)
> >               return;
> >
> > -     ima_kexec_buffer = kimage_map_segment(image,
> > -                                           image->ima_buffer_addr,
> > -                                           image->ima_buffer_size);
> > +     ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index);
> >       if (!ima_kexec_buffer) {
> >               pr_err("Could not map measurements buffer.\n");
> >               return;
> > --
> > 2.49.0
> >
>

Re: [PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Pingfan Liu]

Hi Baoquan,

On Wed, Nov 26, 2025 at 9:10 AM Baoquan He <bhe@redhat.com> wrote:
>
> Hi Pingfan,
>
> On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > The kexec segment index will be required to extract the corresponding
> > information for that segment in kimage_map_segment(). Additionally,
> > kexec_segment already holds the kexec relocation destination address and
> > size. Therefore, the prototype of kimage_map_segment() can be changed.
>
> Because no cover letter, I just reply here.
>
> I am testing code of (tag: next-20251125, next/master) on arm64 system.
> I saw your two patches are already in there. When I used kexec reboot
> as below, I still got the warning message during ima_kexec_post_load()
> invocation.
>
> ====================
> kexec -d -l /boot/vmlinuz-6.18.0-rc7-next-20251125 --initrd /boot/initramfs-6.18.0-rc7-next-20251125.img --reuse-cmdline
> ====================
>

"I have used the Fedora 42 server and its config file to reproduce the
issue you reported here. However, I cannot reproduce it with my patch.
Instead, if I revert my patch, I can see the warning again.

I suspect that you observed the warning thrown by the original Fedora
42 kernel instead of mine.

You need to kexec-reboot into vmlinuz-6.18.0-rc7-next-20251125, and at
that point, try 'kexec -d -l /boot/vmlinuz-6.18.0-rc7-next-20251125
--initrd /boot/initramfs-6.18.0-rc7-next-20251125.img
--reuse-cmdline'.

If this is a false alarm, I will rewrite the commit log and send out v3.


Thanks,

Pingfan

> ====================
> [34283.657670] kexec_file: kernel: 000000006cf71829 kernel_size: 0x48b0000
> [34283.657700] PEFILE: Unsigned PE binary
> [34283.676597] ima: kexec measurement buffer for the loaded kernel at 0xff206000.
> [34283.676621] kexec_file: Loaded initrd at 0x84cb0000 bufsz=0x25ec426 memsz=0x25ed000
> [34283.684646] kexec_file: Loaded dtb at 0xff400000 bufsz=0x39e memsz=0x1000
> [34283.684653] kexec_file(Image): Loaded kernel at 0x80400000 bufsz=0x48b0000 memsz=0x48b0000
> [34283.684663] kexec_file: nr_segments = 4
> [34283.684666] kexec_file: segment[0]: buf=0x0000000000000000 bufsz=0x0 mem=0xff206000 memsz=0x1000
> [34283.684674] kexec_file: segment[1]: buf=0x000000006cf71829 bufsz=0x48b0000 mem=0x80400000 memsz=0x48b0000
> [34283.725987] kexec_file: segment[2]: buf=0x00000000c7369de6 bufsz=0x25ec426 mem=0x84cb0000 memsz=0x25ed000
> [34283.747670] kexec_file: segmen
> ** replaying previous printk message **
> [34283.747670] kexec_file: segment[3]: buf=0x00000000d83b530b bufsz=0x39e mem=0xff400000 memsz=0x1000
> [34283.747973] ------------[ cut here ]------------
> [34283.747976] WARNING: CPU: 33 PID: 16112 at kernel/kexec_core.c:1002 kimage_map_segment+0x138/0x190
> [34283.778574] Modules linked in: rfkill vfat fat ipmi_ssif igb acpi_ipmi ipmi_si ipmi_devintf mlx5_fwctl i2c_algo_bit ipmi_msghandler fwctl fuse loop nfnetlink zram lz4hc_compress lz4_compress xfs mlx5_ib macsec mlx5_core nvme nvme_core mlxfw psample tls nvme_keyring nvme_auth pci_hyperv_intf sbsa_gwdt rpcrdma sunrpc rdma_ucm ib_uverbs ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser i2c_dev ib_umad rdma_cm ib_ipoib iw_cm ib_cm libiscsi ib_core scsi_transport_iscsi aes_neon_bs
> [34283.824233] CPU: 33 UID: 0 PID: 16112 Comm: kexec Tainted: G        W           6.17.8-200.fc42.aarch64 #1 PREEMPT(voluntary)
> [34283.836355] Tainted: [W]=WARN
> [34283.839684] Hardware name: CRAY CS500/CMUD        , BIOS 1.4.0 Jun 17 2020
> [34283.846903] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [34283.854243] pc : kimage_map_segment+0x138/0x190
> [34283.859120] lr : kimage_map_segment+0x4c/0x190
> [34283.863920] sp : ffff8000a0643a90
> [34283.867394] x29: ffff8000a0643a90 x28: ffff800083d0a000 x27: 0000000000000000
> [34283.874901] x26: 0000aaaad722d4b0 x25: 000000000000008f x24: ffff800083d0a000
> [34283.882608] x23: 0000000000000001 x22: 00000000ff206000 x21: 00000000ff207000
> [34283.890305] x20: ffff008fbd306980 x19: ffff008f895d6400 x18: 00000000fffffff9
> [34283.897815] x17: 303d6d656d206539 x16: 3378303d7a736675 x15: 646565732d676e72
> [34283.905516] x14: 00646565732d726c x13: 616d692c78756e69 x12: 6c00636578656b2d
> [34283.912999] x11: 007265666675622d x10: 636578656b2d616d x9 : ffff80008050b73c
> [34283.920691] x8 : 0001000000000000 x7 : 0000000000000000 x6 : 0000000080000000
> [34283.928197] x5 : 0000000084cb0000 x4 : ffff008fbd2306b0 x3 : ffff008fbd305000
> [34283.935898] x2 : fffffff7ff000000 x1 : 0000000000000004 x0 : ffff800082046000
> [34283.943603] Call trace:
> [34283.946039]  kimage_map_segment+0x138/0x190 (P)
> [34283.950935]  ima_kexec_post_load+0x58/0xc0
> [34283.955225]  __do_sys_kexec_file_load+0x2b8/0x398
> [34283.960279]  __arm64_sys_kexec_file_load+0x28/0x40
> [34283.965965]  invoke_syscall.constprop.0+0x64/0xe8
> [34283.971025]  el0_svc_common.constprop.0+0x40/0xe8
> [34283.975883]  do_el0_svc+0x24/0x38
> [34283.979361]  el0_svc+0x3c/0x168
> [34283.982833]  el0t_64_sync_handler+0xa0/0xf0
> [34283.987176]  el0t_64_sync+0x1b0/0x1b8
> [34283.991000] ---[ end trace 0000000000000000 ]---
> [34283.996060] ------------[ cut here ]------------
> [34283.996064] WARNING: CPU: 33 PID: 16112 at mm/vmalloc.c:538 vmap_pages_pte_range+0x2bc/0x3c0
> [34284.010006] Modules linked in: rfkill vfat fat ipmi_ssif igb acpi_ipmi ipmi_si ipmi_devintf mlx5_fwctl i2c_algo_bit ipmi_msghandler fwctl fuse loop nfnetlink zram lz4hc_compress lz4_compress xfs mlx5_ib macsec mlx5_core nvme nvme_core mlxfw psample tls nvme_keyring nvme_auth pci_hyperv_intf sbsa_gwdt rpcrdma sunrpc rdma_ucm ib_uverbs ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser i2c_dev ib_umad rdma_cm ib_ipoib iw_cm ib_cm libiscsi ib_core scsi_transport_iscsi aes_neon_bs
> [34284.055630] CPU: 33 UID: 0 PID: 16112 Comm: kexec Tainted: G        W           6.17.8-200.fc42.aarch64 #1 PREEMPT(voluntary)
> [34284.067701] Tainted: [W]=WARN
> [34284.070833] Hardware name: CRAY CS500/CMUD        , BIOS 1.4.0 Jun 17 2020
> [34284.078238] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [34284.085546] pc : vmap_pages_pte_range+0x2bc/0x3c0
> [34284.090607] lr : vmap_small_pages_range_noflush+0x16c/0x298
> [34284.096528] sp : ffff8000a0643940
> [34284.100001] x29: ffff8000a0643940 x28: 0000000000000000 x27: ffff800084f76000
> [34284.107699] x26: fffffdffc0000000 x25: ffff8000a06439d0 x24: ffff800082046000
> [34284.115174] x23: ffff800084f75000 x22: ffff007f80337ba8 x21: 03ffffffffffffc0
> [34284.122821] x20: ffff008fbd306980 x19: ffff8000a06439d4 x18: 00000000fffffff9
> [34284.130331] x17: 303d6d656d206539 x16: 3378303d7a736675 x15: 646565732d676e72
> [34284.138032] x14: 0000000000004000 x13: ffff009781307130 x12: 0000000000002000
> [34284.145733] x11: 0000000000000000 x10: 0000000000000001 x9 : ffff8000804e197c
> [34284.153248] x8 : 0000000000000027 x7 : ffff800085175000 x6 : ffff8000a06439d4
> [34284.160944] x5 : ffff8000a06439d0 x4 : ffff008fbd306980 x3 : 0068000000000f03
> [34284.168449] x2 : ffff007f80337ba8 x1 : 0000000000000000 x0 : 0000000000000000
> [34284.176150] Call trace:
> [34284.178768]  vmap_pages_pte_range+0x2bc/0x3c0 (P)
> [34284.183665]  vmap_small_pages_range_noflush+0x16c/0x298
> [34284.189264]  vmap+0xb4/0x138
> [34284.192312]  kimage_map_segment+0xdc/0x190
> [34284.196794]  ima_kexec_post_load+0x58/0xc0
> [34284.201044]  __do_sys_kexec_file_load+0x2b8/0x398
> [34284.206107]  __arm64_sys_kexec_file_load+0x28/0x40
> [34284.211254]  invoke_syscall.constprop.0+0x64/0xe8
> [34284.216139]  el0_svc_common.constprop.0+0x40/0xe8
> [34284.221196]  do_el0_svc+0x24/0x38
> [34284.224678]  el0_svc+0x3c/0x168
> [34284.227983]  el0t_64_sync_handler+0xa0/0xf0
> [34284.232526]  el0t_64_sync+0x1b0/0x1b8
> [34284.236376] ---[ end trace 0000000000000000 ]---
> [34284.241412] kexec_core: Could not map ima buffer.
> [34284.241421] ima: Could not map measurements buffer.
> [34284.551336] machine_kexec_post_load:155:
> [34284.551354]   kexec kimage info:
> [34284.551366]     type:        0
> [34284.551373]     head:        90363f9002
> [34284.551377]     kern_reloc: 0x00000090363f7000
> [34284.551381]     el2_vectors: 0x0000000000000000
> [34284.551384] kexec_file: kexec_file_load: type:0, start:0x80400000 head:0x90363f9002 flags:0x8
> ====================
>
> >
> > Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> > Signed-off-by: Pingfan Liu <piliu@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Baoquan He <bhe@redhat.com>
> > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > Cc: Roberto Sassu <roberto.sassu@huawei.com>
> > Cc: Alexander Graf <graf@amazon.com>
> > Cc: Steven Chen <chenste@linux.microsoft.com>
> > Cc: <stable@vger.kernel.org>
> > To: kexec@lists.infradead.org
> > To: linux-integrity@vger.kernel.org
> > ---
> >  include/linux/kexec.h              | 4 ++--
> >  kernel/kexec_core.c                | 9 ++++++---
> >  security/integrity/ima/ima_kexec.c | 4 +---
> >  3 files changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > index ff7e231b0485..8a22bc9b8c6c 100644
> > --- a/include/linux/kexec.h
> > +++ b/include/linux/kexec.h
> > @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print;
> >  #define kexec_dprintk(fmt, arg...) \
> >          do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
> >
> > -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
> > +extern void *kimage_map_segment(struct kimage *image, int idx);
> >  extern void kimage_unmap_segment(void *buffer);
> >  #else /* !CONFIG_KEXEC_CORE */
> >  struct pt_regs;
> > @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
> >  static inline void crash_kexec(struct pt_regs *regs) { }
> >  static inline int kexec_should_crash(struct task_struct *p) { return 0; }
> >  static inline int kexec_crash_loaded(void) { return 0; }
> > -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
> > +static inline void *kimage_map_segment(struct kimage *image, int idx)
> >  { return NULL; }
> >  static inline void kimage_unmap_segment(void *buffer) { }
> >  #define kexec_in_progress false
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index fa00b239c5d9..9a1966207041 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *image, int idx)
> >       return result;
> >  }
> >
> > -void *kimage_map_segment(struct kimage *image,
> > -                      unsigned long addr, unsigned long size)
> > +void *kimage_map_segment(struct kimage *image, int idx)
> >  {
> > +     unsigned long addr, size, eaddr;
> >       unsigned long src_page_addr, dest_page_addr = 0;
> > -     unsigned long eaddr = addr + size;
> >       kimage_entry_t *ptr, entry;
> >       struct page **src_pages;
> >       unsigned int npages;
> >       void *vaddr = NULL;
> >       int i;
> >
> > +     addr = image->segment[idx].mem;
> > +     size = image->segment[idx].memsz;
> > +     eaddr = addr + size;
> > +
> >       /*
> >        * Collect the source pages and map them in a contiguous VA range.
> >        */
> > diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> > index 7362f68f2d8b..5beb69edd12f 100644
> > --- a/security/integrity/ima/ima_kexec.c
> > +++ b/security/integrity/ima/ima_kexec.c
> > @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image)
> >       if (!image->ima_buffer_addr)
> >               return;
> >
> > -     ima_kexec_buffer = kimage_map_segment(image,
> > -                                           image->ima_buffer_addr,
> > -                                           image->ima_buffer_size);
> > +     ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index);
> >       if (!ima_kexec_buffer) {
> >               pr_err("Could not map measurements buffer.\n");
> >               return;
> > --
> > 2.49.0
> >
>

Re: [PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

[Baoquan He]

On 12/03/25 at 12:22pm, Pingfan Liu wrote:
> Hi Baoquan,
> 
> On Wed, Nov 26, 2025 at 9:10 AM Baoquan He <bhe@redhat.com> wrote:
> >
> > Hi Pingfan,
> >
> > On 11/06/25 at 02:59pm, Pingfan Liu wrote:
> > > The kexec segment index will be required to extract the corresponding
> > > information for that segment in kimage_map_segment(). Additionally,
> > > kexec_segment already holds the kexec relocation destination address and
> > > size. Therefore, the prototype of kimage_map_segment() can be changed.
> >
> > Because no cover letter, I just reply here.
> >
> > I am testing code of (tag: next-20251125, next/master) on arm64 system.
> > I saw your two patches are already in there. When I used kexec reboot
> > as below, I still got the warning message during ima_kexec_post_load()
> > invocation.
> >
> > ====================
> > kexec -d -l /boot/vmlinuz-6.18.0-rc7-next-20251125 --initrd /boot/initramfs-6.18.0-rc7-next-20251125.img --reuse-cmdline
> > ====================
> >
> 
> "I have used the Fedora 42 server and its config file to reproduce the
> issue you reported here. However, I cannot reproduce it with my patch.
> Instead, if I revert my patch, I can see the warning again.
> 
> I suspect that you observed the warning thrown by the original Fedora
> 42 kernel instead of mine.
> 
> You need to kexec-reboot into vmlinuz-6.18.0-rc7-next-20251125, and at
> that point, try 'kexec -d -l /boot/vmlinuz-6.18.0-rc7-next-20251125
> --initrd /boot/initramfs-6.18.0-rc7-next-20251125.img
> --reuse-cmdline'.
> 
> If this is a false alarm, I will rewrite the commit log and send out v3.

Thanks for checking, Pingfan. I am not quite sure if I did wrong
operation on the machine. Since you are testing the same machine and the
same linux-next code, and it still can'e be reproduced, it should be
from my mistake. Then please go ahead posting v3.

Thanks
Baoquan