Liao Chang writes:
> The pointer to buffer loading kernel binaries is in kernel space for
> kexec_fil mode, When copy_from_user copies data from pointer to a block
> of memory, it checkes that the pointer is in the user space range, on
> RISCV-V that is:
>
> static inline bool
The pointer to buffer loading kernel binaries is in kernel space for
kexec_fil mode, When copy_from_user copies data from pointer to a block
of memory, it checkes that the pointer is in the user space range, on
RISCV-V that is:
static inline bool __access_ok(unsigned long addr, unsigned long
When CONFIG_KEXEC_FILE is set for riscv platform, the compilation of
kernel/kexec_file.c generate build error:
kernel/kexec_file.c: In function 'crash_prepare_elf64_headers':
./arch/riscv/include/asm/page.h:110:71: error: request for member 'virt_addr'
in something not a structure or union
110
This patchset implement kexec_file_load() support on riscv, Most of the
code is based on the kexec-tool-patch repo developed by Nick Kossifids.
This patch series enables us to load the riscv vmlinux by specifying
its file decriptor, instead of user-filled buffer via kexec_file_load()
syscall.
This patch adds support for kexec_file on RISC-V. I tested it on riscv64
QEMU with busybear-linux and single core along with the OpenSBI firmware
fw_jump.bin for generic platform.
On SMP system, it depends on CONFIG_{HOTPLUG_CPU, RISCV_SBI} to
resume/stop hart through OpenSBI firmware, it also
Hi Baoquan,
On Fri, 29 Oct 2021 17:26:35 +0800
Baoquan He wrote:
> A memory leak is reported by kmemleak scanning:
>
> unreferenced object 0x38000195000 (size 4096):
> comm "kexec", pid 8548, jiffies 4294953647 (age 32443.270s)
> hex dump (first 32 bytes):
> 00 00 00 c8 20 00 00 00 00
On 10/20/21 at 08:39am, cgel@gmail.com wrote:
> From: Changcheng Deng
>
> ./include/linux/crash_dump.h: 119: 50-51: WARNING: return of 0/1 in
> function 'is_kdump_kernel' with return type bool
>
> Return statements in functions returning bool should use true/false
> instead of 1/0.
>
>
On 10/20/21 at 09:06am, cgel@gmail.com wrote:
> From: Ye Guojin
>
> In crash_dump.h, header file is included twice. This
> duplication was introduced in commit 65fddcfca8ad("mm: reorder includes
> after introduction of linux/pgtable.h") where the order of the header
> files is adjusted,
A memory leak is reported by kmemleak scanning:
unreferenced object 0x38000195000 (size 4096):
comm "kexec", pid 8548, jiffies 4294953647 (age 32443.270s)
hex dump (first 32 bytes):
00 00 00 c8 20 00 00 00 00 00 00 c0 02 80 00 00 ...
40 40 40 40 40 40 40 40 00 00 00 00
Function arch_kexec_kernel_image_load() has a common weak version which
is a wrapper of kexec_image_load_default() , and has only one arch
dependent version in x86_64. Now the x86_64 dependent function is not
needed any more. So clean it up.
And also rename kexec_image_load_default() to
This is reported by kmemleak detector:
unreferenced object 0xc92a9000 (size 4096):
comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s)
hex dump (first 32 bytes):
7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF
04 00 3e 00 01 00 00 00 00 00 00 00 00 00
The memory leak is reported by kmemleak detector, has been existing
for very long time. It could casue much memory loss on large machine
with huge memory hotplug which will trigger kdump kernel reloading
many times, with kexec_file_load interface.
And in patch 2, 3, clean up is done to remove
Before calling arch specific kexec_file loading function, the image
instance has been initialized. So 'image->elf_headers' must be NULL.
It doesn't make sense to free the elf header buffer in the place.
So remove it.
Signed-off-by: Baoquan He
---
arch/x86/kernel/machine_kexec_64.c | 3 ---
1
13 matches
Mail list logo
