- 13 Dec, 2022 8 commits
-
-
Palmer Dabbelt authored
Palmer Dabbelt <palmer@rivosinc.com> says: We've had a patch acceptance policy that doesn't match reality, this changes the policy and also makes some more minor cleanups as well. * b4-shazam-merge: Documentation: RISC-V: patch-acceptance: s/implementor/implementer Documentation: RISC-V: Mention the UEFI Standards Documentation: RISC-V: Allow patches for non-standard behavior Documentation: RISC-V: Fix a typo in patch-acceptance Link: https://lore.kernel.org/r/20221207020815.16214-1-palmer@rivosinc.comSigned-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
Palmer Dabbelt authored
Implementor does appear to be a word, but it's not very common. Suggested-by:
Conor Dooley <conor@kernel.org> Reviewed-by:
Anup Patel <anup@brainfault.org> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221207020815.16214-5-palmer@rivosinc.comSigned-off-by:
-
Palmer Dabbelt authored
The current patch acceptance policy requires that specifications are approved by the RISC-V foundation, but we rely on external specifications as well. This explicitly calls out the UEFI specifications that we're starting to depend on. Reviewed-by:
Atish Patra <atishp@rivosinc.com> Reviewed-by:
-
Palmer Dabbelt authored
The patch acceptance policy forbids accepting support for non-standard behavior. This policy was written in order to both steer implementers towards the standards and to avoid coupling the upstream kernel too tightly to vendor-specific features. Those were good goals, but in practice the policy just isn't working: every RISC-V system we have needs vendor-specific behavior in the kernel and we end up taking that support which violates the policy. That's confusing for contributors, which is the main reason we have a written policy in the first place. So let's just start taking code for vendor-defined behavior. Reviewed-by:
Paul Walmsley <paul.walmsley@sifive.com> Link: https://lore.kernel.org/all/alpine.DEB.2.21.999.2211181027590.4480@utopia.booyaka.com/ [Palmer: merge in Paul's suggestions] Link: https://lore.kernel.org/r/20221207020815.16214-3-palmer@rivosinc.comSigned-off-by:
-
Palmer Dabbelt authored
I just stumbled on this when modifying the docs. Reviewed-by:
-
Guo Ren authored
Current nommu_virt_defconfig can't compile: In file included from arch/riscv/kernel/crash_core.c:3: arch/riscv/kernel/crash_core.c: In function 'arch_crash_save_vmcoreinfo': arch/riscv/kernel/crash_core.c:8:27: error: 'VA_BITS' undeclared (first use in this function) 8 | VMCOREINFO_NUMBER(VA_BITS); | ^~~~~~~ Add MMU dependency for KEXEC_FILE. Fixes: 6261586e ("RISC-V: Add kexec_file support") Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
Guo Ren <guoren@kernel.org> Signed-off-by:
Guo Ren <guoren@linux.alibaba.com> Tested-by:
-
Alexandre Ghiti authored
RISC-V kernels support 3,4,5-level page tables at runtime by folding upper levels. In case of a 3-level page table, PGDIR is folded into P4D which in turn is folded into PUD: PGDIR_SHIFT value is correctly set to the same value as PUD_SHIFT, but P4D_SHIFT is not, then any use of P4D_SHIFT will access invalid address bits (all set to 1). Fix this by dynamically defining P4D_SHIFT value, like we already do for PGDIR_SHIFT. Fixes: d10efa21 ("riscv: mm: Control p4d's folding by pgtable_l5_enabled") Signed-off-by:
Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by:
-
Andrew Jones authored
Add a static assert to ensure a RISCV_ISA_EXT_* enum is never created with a value >= RISCV_ISA_EXT_MAX. We can do this by putting RISCV_ISA_EXT_ID_MAX to more work. Before it was redundant with RISCV_ISA_EXT_MAX and hence only used to document the limit. Now it grows with the enum and is used to check the limit. Signed-off-by:
Andrew Jones <ajones@ventanamicro.com> Reviewed-by:
-
- 12 Dec, 2022 3 commits
-
-
Palmer Dabbelt authored
Palmer Dabbelt <palmer@rivosinc.com> says: This contains a pair of cleanups that depend on a fix that has already landed upstream. * b4-shazam-merge: RISC-V: Add some comments about the shadow and overflow stacks RISC-V: Align the shadow stack riscv: fix race when vmap stack overflow Link: https://lore.kernel.org/r/20221130023515.20217-1-palmer@rivosinc.comSigned-off-by:
-
Palmer Dabbelt authored
It took me a while to page all this back in when trying to review the recent spin_shadow_stack, so I figured I'd just write up some comments. Reviewed-by:
Jisheng Zhang <jszhang@kernel.org> Link: https://lore.kernel.org/r/20221130023515.20217-2-palmer@rivosinc.comSigned-off-by:
-
Palmer Dabbelt authored
The standard RISC-V ABIs all require 16-byte stack alignment. We're only calling that one function on the shadow stack so I doubt it'd result in a real issue, but might as well keep this lined up. Fixes: 31da94c2 ("riscv: add VMAP_STACK overflow detection") Reviewed-by:
-
- 10 Dec, 2022 9 commits
-
-
Palmer Dabbelt authored
Andrew Jones <ajones@ventanamicro.com> says: This series is a collection of cleanups for alternative-macros.h with the main motivation being that adding new ALTERNATIVE_3, ALTERNATIVE_4, ... will be possible without lots of bloat. * b4-shazam-merge: riscv: Don't duplicate _ALTERNATIVE_CFG* macros riscv: alternatives: Drop the underscores from the assembly macro names riscv: alternatives: Don't name unused macro parameters riscv: Don't duplicate __ALTERNATIVE_CFG in __ALTERNATIVE_CFG_2 Link: https://lore.kernel.org/r/20221129150053.50464-1-ajones@ventanamicro.comSigned-off-by:
-
Palmer Dabbelt authored
Andrew Jones <ajones@ventanamicro.com> says: When a DT puts zicbom in the isa string, but does not provide a block size, ALT_CMO_OP() will attempt to do cache operations on address zero since the start address will be ANDed with zero. We can't simply BUG() in riscv_init_cbom_blocksize() when we fail to find a block size because the failure will happen before logging works, leaving users to scratch their heads as to why the boot hung. Instead, ensure Zicbom is disabled and output an error which will hopefully alert people that the DT needs to be fixed. While at it, add a check that the block size is a power-of-2 too. * b4-shazam-merge: RISC-V: Ensure Zicbom has a valid block size RISC-V: Introduce riscv_isa_extension_check RISC-V: Improve use of isa2hwcap[] Link: https://lore.kernel.org/r/20221129143447.49714-1-ajones@ventanamicro.comSigned-off-by:
-
Andrew Jones authored
When a DT puts zicbom in the isa string, but does not provide a block size, ALT_CMO_OP() will attempt to do cache operations on address zero since the start address will be ANDed with zero. We can't simply BUG() in riscv_init_cbom_blocksize() when we fail to find a block size because the failure will happen before logging works, leaving users to scratch their heads as to why the boot hung. Instead, ensure Zicbom is disabled and output an error which will hopefully alert people that the DT needs to be fixed. While at it, add a check that the block size is a power-of-2 too. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20221129143447.49714-4-ajones@ventanamicro.com [Palmer: base on 5c20a3a9 ("RISC-V: Fix compilation without RISCV_ISA_ZICBOM"] Reported-by:
-
Andrew Jones authored
Currently any isa extension found in the isa string is set in the isa bitmap. An isa extension set in the bitmap indicates that the extension is present and may be used (a.k.a is enabled). However, when an extension cannot be used due to missing dependencies or errata it should not be added to the bitmap. Introduce a function where additional checks may be placed in order to determine if an extension should be enabled or not. Note, the checks may simply indicate an issue with the DT, but, since extensions may be used in early boot, it's not always possible to simply produce an error at the point the issue is determined. It's best to keep the extension disabled and produce an error. No functional change intended, as the function is only introduced and always returns true. A later patch will provide checks for an isa extension. Signed-off-by:
-
Andrew Jones authored
Improve isa2hwcap[] by removing it from static storage, as riscv_fill_hwcap() is only called once, and by reducing its size from 256 bytes to 26. The latter improvement is possible because isa2hwcap[] will never be indexed with capital letters and we can precompute the offsets from 'a'. No functional change intended. Signed-off-by:
-
Andrew Jones authored
Reduce clutter by only defining the _ALTERNATIVE_CFG* macros once, rather than once for assembly and once for C. To do that, we need to add __ALTERNATIVE_CFG* macros to the assembly side, but those are one-liners. Also take the opportunity to do a bit of reformatting, taking full advantage of the fact checkpatch gives us 100 char lines. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by:
-
Andrew Jones authored
The underscores aren't needed because there isn't anything already named without them and the _CFG extension. This is a bit of a cleanup by itself, but the real motivation is for a coming patch which would otherwise need to add two more underscores to these macro names, i.e. ____ALTERNATIVE_CFG, and that'd be gross. Signed-off-by:
-
Andrew Jones authored
Without CONFIG_RISCV_ALTERNATIVE only the first parameter of the ALTERNATIVE macros is needed. Use ... for the rest to cut down on clutter. While there, fix a couple space vs. tab issues. Signed-off-by:
-
Andrew Jones authored
Build __ALTERNATIVE_CFG_2 by adding on to __ALTERNATIVE_CFG rather than duplicating it. Signed-off-by:
-
- 09 Dec, 2022 6 commits
-
-
Qinglin Pan authored
Modify the best_map_size function to give map_size many times instead of only once, so a memory region can be mapped by both PMD_SIZE and PAGE_SIZE. Signed-off-by:
Qinglin Pan <panqinglin2020@iscas.ac.cn> Reviewed-by:
-
Palmer Dabbelt authored
These are fixes, but due to the possible early boot fallout they're going in the merge window to get a bit more time to bake on linux-next. * b4-shazam-merge riscv: Move cast inside kernel_mapping_[pv]a_to_[vp]a riscv: Fix crash during early errata patching Link: https://lore.kernel.org/r/20221126060920.65009-1-samuel@sholland.orgSigned-off-by:
-
Samuel Holland authored
Before commit 44c92257 ("RISC-V: enable XIP"), these macros cast their argument to unsigned long. That commit moved the cast after an assignment to an unsigned long variable, rendering it ineffectual. Move the cast back, so we can remove the cast at each call site. Reviewed-by:
Alexandre Ghiti <alexandre.ghiti@canonical.com> Reviewed-by:
Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20221126060920.65009-2-samuel@sholland.orgSigned-off-by:
-
Samuel Holland authored
The patch function for the T-Head PBMT errata calls __pa_symbol() before relocation. This crashes when CONFIG_DEBUG_VIRTUAL is enabled, because __pa_symbol() forwards to __phys_addr_symbol(), and __phys_addr_symbol() checks against the absolute kernel start/end address. Fix this by checking against the kernel map instead of a symbol address. Fixes: a35707c3 ("riscv: add memory-type errata for T-Head") Reviewed-by:
-
Jisheng Zhang authored
Support build the zstd compressed Image.zst. Similar as other compressed formats, the Image.zst is not self-decompressing and the bootloader still needs to handle decompression before launching the kernel image. Signed-off-by:
-
Palmer Dabbelt authored
Conor Dooley <conor@kernel.org> says: From: Conor Dooley <conor.dooley@microchip.com> Submitted a patch yesterday defaulting the SiFive PLIC driver to enabled [0], and in the ensuing conversation Marc suggested just doing a select at the arch level and dropping the user selectability completely. * b4-shazam-merge: RISC-V: stop selecting SIFIVE_PLIC at the SoC level irqchip/riscv-intc: remove user selectability of RISCV_INTC irqchip/sifive-plic: remove user selectability of SIFIVE_PLIC Link: https://lore.kernel.org/r/20221118104300.85016-1-conor@kernel.orgAcked-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/all/87zgceszp8.wl-maz@kernel.org/Signed-off-by:
-
- 08 Dec, 2022 10 commits
-
-
Conor Dooley authored
The SIFIVE_PLIC driver is used by all current RISC-V SoCs & will be, where possible, used for future implementations. Rather than having each driver select the option on a case-by-case basis, do so at the arch level. Signed-off-by:
-
Conor Dooley authored
Since commit e71ee06e ("RISC-V: Force select RISCV_INTC for CONFIG_RISCV") the driver has been enabled at the arch level - and is mandatory anyway. There's no point exposing this as a choice to users, so stop bothering. Signed-off-by:
-
Conor Dooley authored
The SiFive PLIC driver is used by all current implementations, including those that do not have a SiFive PLIC. The current driver supports more than just SiFive PLICs at present and, where possible, future PLIC implementations will also use this driver. As every supported RISC-V SoC selects the driver directly in Kconfig.socs there's no point in exposing this kconfig option to users. The Kconfig help text, in its current form, is misleading. There's no point doing anything about that though, as it will no longer be user selectable. Remove it. Suggested-by:
-
Palmer Dabbelt authored
Anup Patel <apatel@ventanamicro.com> says: The Linux NVDIMM PEM drivers require arch support to map and access the persistent memory device. This series adds RISC-V PMEM support using recently added Svpbmt and Zicbom support. * b4-shazam-merge: RISC-V: Enable PMEM drivers RISC-V: Implement arch specific PMEM APIs RISC-V: Fix MEMREMAP_WB for systems with Svpbmt Link: https://lore.kernel.org/r/20221114090536.1662624-1-apatel@ventanamicro.comSigned-off-by:
-
Anup Patel authored
We now have PMEM arch support available in RISC-V kernel so let us enable relevant drivers in defconfig. Signed-off-by:
Anup Patel <apatel@ventanamicro.com> Acked-by:
-
Anup Patel authored
The NVDIMM PMEM driver expects arch specific APIs for cache maintenance and if arch does not provide these APIs then NVDIMM PMEM driver will always use MEMREMAP_WT to map persistent memory which in-turn maps as UC memory type defined by the RISC-V Svpbmt specification. Now that the Svpbmt and Zicbom support is available in RISC-V kernel, we implement PMEM APIs using ALT_CMO_OP() macros so that the NVDIMM PMEM driver can use MEMREMAP_WB to map persistent memory. Co-developed-by:
Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by:
-
Anup Patel authored
Currently, the memremap() called with MEMREMAP_WB maps memory using the generic ioremap() function which breaks on system with Svpbmt because memory mapped using _PAGE_IOREMAP page attributes is treated as strongly-ordered non-cacheable IO memory. To address this, we implement RISC-V specific arch_memremap_wb() which maps memory using _PAGE_KERNEL page attributes resulting in write-back cacheable mapping on systems with Svpbmt. Fixes: ff689fd2 ("riscv: add RISC-V Svpbmt extension support") Co-developed-by:
-
Palmer Dabbelt authored
I'm merging this in as a single patch to make it easier to handle the backports. * b4-shazam-merge: RISC-V: Fix unannoted hardirqs-on in return to userspace slow-path Link: https://lore.kernel.org/r/20221111223108.1976562-1-abrestic@rivosinc.comSigned-off-by:
-
Andrew Bresticker authored
The return to userspace path in entry.S may enable interrupts without the corresponding lockdep annotation, producing a splat[0] when DEBUG_LOCKDEP is enabled. Simply calling __trace_hardirqs_on() here gets a bit messy due to the use of RA to point back to ret_from_exception, so just move the whole slow-path loop into C. It's more readable and it lets us use local_irq_{enable,disable}(), avoiding the need for manual annotations altogether. [0]: ------------[ cut here ]------------ DEBUG_LOCKS_WARN_ON(!lockdep_hardirqs_enabled()) WARNING: CPU: 2 PID: 1 at kernel/locking/lockdep.c:5512 check_flags+0x10a/0x1e0 Modules linked in: CPU: 2 PID: 1 Comm: init Not tainted 6.1.0-rc4-00160-gb56b6e2b4f31 #53 Hardware name: riscv-virtio,qemu (DT) epc : check_flags+0x10a/0x1e0 ra : check_flags+0x10a/0x1e0 <snip> status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [<ffffffff808edb90>] lock_is_held_type+0x78/0x14e [<ffffffff8003dae2>] __might_resched+0x26/0x22c [<ffffffff8003dd24>] __might_sleep+0x3c/0x66 [<ffffffff80022c60>] get_signal+0x9e/0xa70 [<ffffffff800054a2>] do_notify_resume+0x6e/0x422 [<ffffffff80003c68>] ret_from_exception+0x0/0x10 irq event stamp: 44512 hardirqs last enabled at (44511): [<ffffffff808f901c>] _raw_spin_unlock_irqrestore+0x54/0x62 hardirqs last disabled at (44512): [<ffffffff80008200>] __trace_hardirqs_off+0xc/0x14 softirqs last enabled at (44472): [<ffffffff808f9fbe>] __do_softirq+0x3de/0x51e softirqs last disabled at (44467): [<ffffffff80017760>] irq_exit+0xd6/0x104 ---[ end trace 0000000000000000 ]--- possible reason: unannotated irqs-on. Signed-off-by:Andrew Bresticker <abrestic@rivosinc.com> Fixes: 3c469798 ("riscv: Enable LOCKDEP_SUPPORT & fixup TRACE_IRQFLAGS_SUPPORT") Link: https://lore.kernel.org/r/20221111223108.1976562-1-abrestic@rivosinc.comSigned-off-by:
-
Sergey Matyukevich authored
Current implementation of update_mmu_cache function performs local TLB flush. It does not take into account ASID information. Besides, it does not take into account other harts currently running the same mm context or possible migration of the running context to other harts. Meanwhile TLB flush is not performed for every context switch if ASID support is enabled. Patch [1] proposed to add ASID support to update_mmu_cache to avoid flushing local TLB entirely. This patch takes into account other harts currently running the same mm context as well as possible migration of this context to other harts. For this purpose the approach from flush_icache_mm is reused. Remote harts currently running the same mm context are informed via SBI calls that they need to flush their local TLBs. All the other harts are marked as needing a deferred TLB flush when this mm context runs on them. [1] https://lore.kernel.org/linux-riscv/20220821013926.8968-1-tjytimi@163.com/Signed-off-by:
Sergey Matyukevich <sergey.matyukevich@syntacore.com> Fixes: 65d4b9c5 ("RISC-V: Implement ASID allocator") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-riscv/20220829205219.283543-1-geomatsi@gmail.com/#tSigned-off-by:
-
- 06 Dec, 2022 2 commits
-
-
Guo Ren authored
The current walk_stackframe with FRAME_POINTER would stop unwinding at ret_from_exception: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1518 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: init CPU: 0 PID: 1 Comm: init Not tainted 5.10.113-00021-g15c15974895c-dirty #192 Call Trace: [<ffffffe0002038c8>] walk_stackframe+0x0/0xee [<ffffffe000aecf48>] show_stack+0x32/0x4a [<ffffffe000af1618>] dump_stack_lvl+0x72/0x8e [<ffffffe000af1648>] dump_stack+0x14/0x1c [<ffffffe000239ad2>] ___might_sleep+0x12e/0x138 [<ffffffe000239aec>] __might_sleep+0x10/0x18 [<ffffffe000afe3fe>] down_read+0x22/0xa4 [<ffffffe000207588>] do_page_fault+0xb0/0x2fe [<ffffffe000201b80>] ret_from_exception+0x0/0xc The optimization would help walk_stackframe cross the pt_regs frame and get more backtrace of debug info: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1518 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: init CPU: 0 PID: 1 Comm: init Not tainted 5.10.113-00021-g15c15974895c-dirty #192 Call Trace: [<ffffffe0002038c8>] walk_stackframe+0x0/0xee [<ffffffe000aecf48>] show_stack+0x32/0x4a [<ffffffe000af1618>] dump_stack_lvl+0x72/0x8e [<ffffffe000af1648>] dump_stack+0x14/0x1c [<ffffffe000239ad2>] ___might_sleep+0x12e/0x138 [<ffffffe000239aec>] __might_sleep+0x10/0x18 [<ffffffe000afe3fe>] down_read+0x22/0xa4 [<ffffffe000207588>] do_page_fault+0xb0/0x2fe [<ffffffe000201b80>] ret_from_exception+0x0/0xc [<ffffffe000613c06>] riscv_intc_irq+0x1a/0x72 [<ffffffe000201b80>] ret_from_exception+0x0/0xc [<ffffffe00033f44a>] vma_link+0x54/0x160 [<ffffffe000341d7a>] mmap_region+0x2cc/0x4d0 [<ffffffe000342256>] do_mmap+0x2d8/0x3ac [<ffffffe000326318>] vm_mmap_pgoff+0x70/0xb8 [<ffffffe00032638a>] vm_mmap+0x2a/0x36 [<ffffffe0003cfdde>] elf_map+0x72/0x84 [<ffffffe0003d05f8>] load_elf_binary+0x69a/0xec8 [<ffffffe000376240>] bprm_execve+0x246/0x53a [<ffffffe00037786c>] kernel_execve+0xe8/0x124 [<ffffffe000aecdf2>] run_init_process+0xfa/0x10c [<ffffffe000aece16>] try_to_run_init_process+0x12/0x3c [<ffffffe000afa920>] kernel_init+0xb4/0xf8 [<ffffffe000201b80>] ret_from_exception+0x0/0xc Here is the error injection test code for the above output: drivers/irqchip/irq-riscv-intc.c: static asmlinkage void riscv_intc_irq(struct pt_regs *regs) { unsigned long cause = regs->cause & ~CAUSE_IRQ_FLAG; + u32 tmp; __get_user(tmp, (u32 *)0); Signed-off-by: -
Guo Ren authored
The 'retp' is a pointer to the return address on the stack, so we must pass the current return address pointer as the 'retp' argument to ftrace_push_return_trace(). Not parent function's return address on the stack. Fixes: b785ec12 ("riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support") Signed-off-by:
-
- 05 Dec, 2022 2 commits
-
-
Li Huafei authored
This is reported by kmemleak detector: unreferenced object 0xff2000000403d000 (size 4096): comm "kexec", pid 146, jiffies 4294900633 (age 64.792s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 f3 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000566ca97c>] kmemleak_vmalloc+0x3c/0xbe [<00000000979283d8>] __vmalloc_node_range+0x3ac/0x560 [<00000000b4b3712a>] __vmalloc_node+0x56/0x62 [<00000000854f75e2>] vzalloc+0x2c/0x34 [<00000000e9a00db9>] crash_prepare_elf64_headers+0x80/0x30c [<0000000067e8bf48>] elf_kexec_load+0x3e8/0x4ec [<0000000036548e09>] kexec_image_load_default+0x40/0x4c [<0000000079fbe1b4>] sys_kexec_file_load+0x1c4/0x322 [<0000000040c62c03>] ret_from_syscall+0x0/0x2 In elf_kexec_load(), a buffer is allocated via vzalloc() to store elf headers. While it's not freed back to system when kdump kernel is reloaded or unloaded, or when image->elf_header is successfully set and then fails to load kdump kernel for some reason. Fix it by freeing the buffer in arch_kimage_file_post_load_cleanup(). Fixes: 8acea455 ("RISC-V: Support for kexec_file on panic") Signed-off-by:Li Huafei <lihuafei1@huawei.com> Reviewed-by:
-
Li Huafei authored
This is reported by kmemleak detector: unreferenced object 0xff60000082864000 (size 9588): comm "kexec", pid 146, jiffies 4294900634 (age 64.788s) hex dump (first 32 bytes): d0 0d fe ed 00 00 12 ed 00 00 00 48 00 00 11 40 ...........H...@ 00 00 00 28 00 00 00 11 00 00 00 02 00 00 00 00 ...(............ backtrace: [<00000000f95b17c4>] kmemleak_alloc+0x34/0x3e [<00000000b9ec8e3e>] kmalloc_order+0x9c/0xc4 [<00000000a95cf02e>] kmalloc_order_trace+0x34/0xb6 [<00000000f01e68b4>] __kmalloc+0x5c2/0x62a [<000000002bd497b2>] kvmalloc_node+0x66/0xd6 [<00000000906542fa>] of_kexec_alloc_and_setup_fdt+0xa6/0x6ea [<00000000e1166bde>] elf_kexec_load+0x206/0x4ec [<0000000036548e09>] kexec_image_load_default+0x40/0x4c [<0000000079fbe1b4>] sys_kexec_file_load+0x1c4/0x322 [<0000000040c62c03>] ret_from_syscall+0x0/0x2 In elf_kexec_load(), a buffer is allocated via kvmalloc() to store fdt. While it's not freed back to system when kexec kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing riscv specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. Fixes: 6261586e ("RISC-V: Add kexec_file support") Signed-off-by:Liao Chang <liaochang1@huawei.com> Link: https://lore.kernel.org/r/20221104095658.141222-1-lihuafei1@huawei.com Cc: stable@vger.kernel.org Signed-off-by:
-
