- 22 Feb, 2023 4 commits
-
-
Heiko Stuebner authored
As Andrew reported, Zb* comes after Zi* according 27.11 "Subset Naming Convention" so fix the ordering accordingly. Reported-by:Andrew Jones <ajones@ventanamicro.com> Signed-off-by:
Heiko Stuebner <heiko.stuebner@vrull.eu> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
Andy Chiu authored
Runtime code patching must be done at a naturally aligned address, or we may execute on a partial instruction. We have encountered problems traced back to static jump functions during the test. We switched the tracer randomly for every 1~5 seconds on a dual-core QEMU setup and found the kernel sucking at a static branch where it jumps to itself. The reason is that the static branch was 2-byte but not 4-byte aligned. Then, the kernel would patch the instruction, either J or NOP, with two half-word stores if the machine does not have efficient unaligned accesses. Thus, moments exist where half of the NOP mixes with the other half of the J when transitioning the branch. In our particular case, on a little-endian machine, the upper half of the NOP was mixed with the lower part of the J when enabling the branch, resulting in a jump that jumped to itself. Conversely, it would result in a HINT instruction when disabling the branch, but it might not be observable. ARM64 does not have this problem since all instructions must be 4-byte aligned. Fixes: ebc00dde ("riscv: Add jump-label implementation") Link: https://lore.kernel.org/linux-riscv/20220913094252.3555240-6-andy.chiu@sifive.com/Reviewed-by:
Greentime Hu <greentime.hu@sifive.com> Signed-off-by:
Andy Chiu <andy.chiu@sifive.com> Signed-off-by:
Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20230206090440.1255001-1-guoren@kernel.org Cc: stable@vger.kernel.org Signed-off-by:
-
Palmer Dabbelt authored
The recent refactoring led to us leaking some HWCAP bits to userspace that didn't make much sense. With any luck we'll have a better scheme soon, but for now just mask off those bits to avoid polluting userspace. Acked-by:
-
Sergey Matyukevich authored
This is a partial revert of the commit 4bd1d80e ("riscv: mm: notify remote harts about mmu cache updates"). Original commit included two loosely related changes serving the same purpose of fixing stale TLB entries causing user-space application crash: - introduce deferred per-ASID TLB flush for CPUs not running the task - switch to per-ASID TLB flush on all CPUs running the task in update_mmu_cache According to report and discussion in [1], the second part caused a regression on Renesas RZ/Five SoC. For now restore the old behavior of the update_mmu_cache. [1] https://lore.kernel.org/linux-riscv/20220829205219.283543-1-geomatsi@gmail.com/ Fixes: 4bd1d80e ("riscv: mm: notify remote harts about mmu cache updates") Reported-by:
"Lad, Prabhakar" <prabhakar.csengg@gmail.com> Signed-off-by:
Sergey Matyukevich <sergey.matyukevich@syntacore.com> Link: trailer, so that it can be parsed with git's trailer functionality? Reviewed-by:
-
- 16 Feb, 2023 1 commit
-
-
Heiko Stuebner authored
The __RISCV_INSN_FUNCS originally declared riscv_insn_is_* functions inside the kprobes implementation. This got moved into a central header in commit ec5f9087 ("RISC-V: Move riscv_insn_is_* macros into a common header"). Though it looks like I overlooked two of them, so fix that. FENCE itself is an instruction defined directly by its own opcode, while the created riscv_isn_is_system function covers all instructions defined under the SYSTEM opcode. Reviewed-by:
-
- 15 Feb, 2023 15 commits
-
-
Palmer Dabbelt authored
guoren@kernel.org <guoren@kernel.org> says: From: Guo Ren <guoren@linux.alibaba.com> The previous ftrace detour implementation fc76b8b8011 ("riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT") contain three problems. - The most horrible bug is preemption panic which found by Andy [1]. Let's disable preemption for ftrace first, and Andy could continue the ftrace preemption work. - The "-fpatchable-function-entry= CFLAG" wasted code size !RISCV_ISA_C. - The ftrace detour implementation wasted code size. - When livepatching, the trampoline (ftrace_regs_caller) would not return to <func_prolog+12> but would rather jump to the new function. So, "REG_L ra, -SZREG(sp)" would not run and the original return address would not be restored. The kernel is likely to hang or crash as a result. (Found by Evgenii Shatokhin [4]) [Palmer: The first three patches in this series are pretty concrete fixes, so I'm pulling them ahead of the rest of the series.] * b4-shazam-merge: riscv: ftrace: Reduce the detour code size to half riscv: ftrace: Remove wasted nops for !RISCV_ISA_C riscv: ftrace: Fixup panic by disabling preemption Link: https://lore.kernel.org/r/20230112090603.1295340-1-guoren@kernel.orgSigned-off-by: -
Guo Ren authored
Use a temporary register to reduce the size of detour code from 16 bytes to 8 bytes. The previous implementation is from 'commit afc76b8b ("riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT")'. Before the patch: <func_prolog>: 0: REG_S ra, -SZREG(sp) 4: auipc ra, ? 8: jalr ?(ra) 12: REG_L ra, -SZREG(sp) (func_boddy) After the patch: <func_prolog>: 0: auipc t0, ? 4: jalr t0, ?(t0) (func_boddy) This patch not just reduces the size of detour code, but also fixes an important issue: An Ftrace callback registered with FTRACE_OPS_FL_IPMODIFY flag can actually change the instruction pointer, e.g. to "replace" the given kernel function with a new one, which is needed for livepatching, etc. In this case, the trampoline (ftrace_regs_caller) would not return to <func_prolog+12> but would rather jump to the new function. So, "REG_L ra, -SZREG(sp)" would not run and the original return address would not be restored. The kernel is likely to hang or crash as a result. This can be easily demonstrated if one tries to "replace", say, cmdline_proc_show() with a new function with the same signature using instruction_pointer_set(&fregs->regs, new_func_addr) in the Ftrace callback. Link: https://lore.kernel.org/linux-riscv/20221122075440.1165172-1-suagrfillet@gmail.com/ Link: https://lore.kernel.org/linux-riscv/d7d5730b-ebef-68e5-5046-e763e1ee6164@yadro.com/Co-developed-by:
Song Shuai <suagrfillet@gmail.com> Signed-off-by:
Guo Ren <guoren@linux.alibaba.com> Signed-off-by:
Evgenii Shatokhin <e.shatokhin@yadro.com> Link: https://lore.kernel.org/r/20230112090603.1295340-4-guoren@kernel.org Cc: stable@vger.kernel.org Fixes: 10626c32 ("riscv/ftrace: Add basic support") Signed-off-by:
-
Guo Ren authored
When CONFIG_RISCV_ISA_C=n, -fpatchable-function-entry=8 would generate more nops than we expect. Because it treat nop opcode as 0x00000013 instead of 0x0001. Dump of assembler code for function dw_pcie_free_msi: 0xffffffff806fce94 <+0>: sd ra,-8(sp) 0xffffffff806fce98 <+4>: auipc ra,0xff90f 0xffffffff806fce9c <+8>: jalr -684(ra) # 0xffffffff8000bbec <ftrace_caller> 0xffffffff806fcea0 <+12>: ld ra,-8(sp) 0xffffffff806fcea4 <+16>: nop /* wasted */ 0xffffffff806fcea8 <+20>: nop /* wasted */ 0xffffffff806fceac <+24>: nop /* wasted */ 0xffffffff806fceb0 <+28>: nop /* wasted */ 0xffffffff806fceb4 <+0>: addi sp,sp,-48 0xffffffff806fceb8 <+4>: sd s0,32(sp) 0xffffffff806fcebc <+8>: sd s1,24(sp) 0xffffffff806fcec0 <+12>: sd s2,16(sp) 0xffffffff806fcec4 <+16>: sd s3,8(sp) 0xffffffff806fcec8 <+20>: sd ra,40(sp) 0xffffffff806fcecc <+24>: addi s0,sp,48 Signed-off-by:
-
Andy Chiu authored
In RISCV, we must use an AUIPC + JALR pair to encode an immediate, forming a jump that jumps to an address over 4K. This may cause errors if we want to enable kernel preemption and remove dependency from patching code with stop_machine(). For example, if a task was switched out on auipc. And, if we changed the ftrace function before it was switched back, then it would jump to an address that has updated 11:0 bits mixing with previous XLEN:12 part. p: patched area performed by dynamic ftrace ftrace_prologue: p| REG_S ra, -SZREG(sp) p| auipc ra, 0x? ------------> preempted ... change ftrace function ... p| jalr -?(ra) <------------- switched back p| REG_L ra, -SZREG(sp) func: xxx ret Fixes: afc76b8b ("riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT") Signed-off-by:
-
Palmer Dabbelt authored
Conor Dooley <conor@kernel.org> says: From: Conor Dooley <conor.dooley@microchip.com> I've yoinked patch 1 from Drew's series adding support for Zicboz & attached two more patches here that remove the need for, and then drop the toolchain support checks for Zicbom. The goal is to remove the need for checking the presence of toolchain Zicbom support in the work being done to support non instruction based CMOs [1]. I've tested compliation on a number of different configurations with the Zicbom config option enabled. The important ones to call out I guess are: - clang/llvm 14 w/ LLVM=1 which doesn't support Zicbom atm. - gcc 11 w/ binutils 2.37 which doesn't support Zicbom atm either. - clang/llvm 15 w/ LLVM=1 BUT with binutils 2.37's ld. This is the configuration that prompted adding the LD checks as cc/as supports Zicbom, but ld doesn't [2]. - gcc 12 w/ binutils 2.39 & clang 15 w/ LLVM=1, both of these supported Zicbom before and still do. I also checked building the THEAD errata etc with CONFIG_RISCV_ISA_ZICBOM disabled, and there were no build issues there either. * b4-shazam-merge: RISC-V: remove toolchain version checks for Zicbom RISC-V: replace cbom instructions with an insn-def RISC-V: insn-def: Add I-type insn-def Link: https://lore.kernel.org/r/20230108163356.3063839-1-conor@kernel.orgSigned-off-by:
-
Conor Dooley authored
Commit b8c86872 ("riscv: fix detection of toolchain Zicbom support") fixed building on systems where Zicbom was supported by the compiler/assembler but not by the linker in an easily backportable manner. Now that the we have insn-defs for the 3 instructions, toolchain support is no longer required for Zicbom. Stop emitting "_zicbom" in -march when Zicbom is enabled & drop the version checks entirely. Signed-off-by:
-
Conor Dooley authored
Using the cbom instructions directly in ALT_CMO_OP, requires toolchain support for the instructions. Using an insn-def will allow for removal of toolchain version checks in the build system & simplification of the proposed [1] function-based CMO scheme. Link: https://lore.kernel.org/linux-riscv/fb3b34ae-e35e-4dc2-a8f4-19984a2f58a8@app.fastmail.com/ [1] Signed-off-by:
-
Andrew Jones authored
CBO instructions use the I-type of instruction format where the immediate is used to identify the CBO instruction type. Add I-type instruction encoding support to insn-def. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Palmer Dabbelt authored
Conor Dooley <conor@kernel.org> says: From: Conor Dooley <conor.dooley@microchip.com> Ever since RISC-V starting using generic arch topology code, the code paths for cpu-capacity have been there but there's no binding defined to actually convey the information. Defining the same property as used on arm seems to be the only logical thing to do, so do it. [Palmer: This is on top of the fix required to make it work, which itself wasn't merged until late in the 6.2 cycle and thus pulls in various other fixes.] * b4-shazam-merge: dt-bindings: riscv: add a capacity-dmips-mhz cpu property dt-bindings: arm: move cpu-capacity to a shared loation riscv: Move call to init_cpu_topology() to later initialization stage riscv/kprobe: Fix instruction simulation of JALR riscv: fix -Wundef warning for CONFIG_RISCV_BOOT_SPINWAIT MAINTAINERS: add an IRC entry for RISC-V RISC-V: fix compile error from deduplicated __ALTERNATIVE_CFG_2 dt-bindings: riscv: fix single letter canonical order dt-bindings: riscv: fix underscore requirement for multi-letter extensions riscv: uaccess: fix type of 0 variable on error in get_user() riscv, kprobes: Stricter c.jr/c.jalr decoding Link: https://lore.kernel.org/r/20230104180513.1379453-1-conor@kernel.orgSigned-off-by:
-
Conor Dooley authored
Since commit 03f11f03 ("RISC-V: Parse cpu topology during boot.") RISC-V has used the generic arch topology code, which provides for disparate CPU capacities. We never defined a binding to acquire this information from the DT though, so document the one already used by the generic arch topology code: "capacity-dmips-mhz". Signed-off-by:
Ley Foon Tan <leyfoon.tan@starfivetech.com> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230104180513.1379453-3-conor@kernel.orgSigned-off-by:
-
Conor Dooley authored
RISC-V uses the same generic topology code as arm64 & while there currently exists no binding for cpu-capacity on RISC-V, the code paths can be hit if the property is present. Move the documentation of cpu-capacity to a shared location, ahead of defining a binding for capacity-dmips-mhz on RISC-V. Update some references to this document in the process. Signed-off-by:
Yanteng Si <siyanteng@loongson.cn> Link: https://lore.kernel.org/r/20230104180513.1379453-2-conor@kernel.orgSigned-off-by:
-
Samuel Holland authored
Commit 4bf88607 ("riscv: cpufeature: extend riscv_cpufeature_patch_func to all ISA extensions") switched ISA extension alternatives to use the RISCV_ISA_EXT_* macros instead of CPUFEATURE_*. This was mismerged when applied on top of the Zbb series, so the Zbb alternatives referenced the wrong errata ID values. Fixes: 9daca9a5 ("Merge patch series "riscv: improve boot time isa extensions handling"") Signed-off-by:
Samuel Holland <samuel@sholland.org> Reviewed-by:
-
Samuel Holland authored
Now that the text to patch is located using a relative offset from the alternative entry, the text address should be computed without applying the kernel mapping offset, both before and after VM setup. Fixes: 8d23e94a ("riscv: switch to relative alternative entries") Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Tested-by:
-
Conor Dooley authored
Selects should be sorted alphanumerically, and were tidied up originally by Palmer in commit e8c7ef7d ("RISC-V: Sort select statements alphanumerically") since then, things have gotten out of order again. Fish RMK's original script out of commit b1b3f49c ("ARM: config: sort select statements alphanumerically") and do some spring cleaning. Signed-off-by:
Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20221219172836.134709-1-conor@kernel.orgSigned-off-by:
-
Conor Dooley authored
When adding the ISA string ordering rules, I didn't sufficiently indent one of the list items. Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/linux-doc/202301300743.bp7Dpazv-lkp@intel.com/ Fixes: f07b2b3f ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") Signed-off-by:
Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20230129235701.2393241-1-conor@kernel.orgSigned-off-by:
-
- 02 Feb, 2023 1 commit
-
-
Palmer Dabbelt authored
Jisheng Zhang <jszhang@kernel.org> says: Generally, riscv ISA extensions are fixed for any specific hardware platform, so a hart's features won't change after booting, this chacteristic makes it straightforward to use a static branch to check a specific ISA extension is supported or not to optimize performance. However, some ISA extensions such as SVPBMT and ZICBOM are handled via. the alternative sequences. Basically, for ease of maintenance, we prefer to use static branches in C code, but recently, Samuel found that the static branch usage in cpu_relax() breaks building with CONFIG_CC_OPTIMIZE_FOR_SIZE[1]. As Samuel pointed out, "Having a static branch in cpu_relax() is problematic because that function is widely inlined, including in some quite complex functions like in the VDSO. A quick measurement shows this static branch is responsible by itself for around 40% of the jump table." Samuel's findings pointed out one of a few downsides of static branches usage in C code to handle ISA extensions detected at boot time: static branch's metadata in the __jump_table section, which is not discarded after ISA extensions are finalized, wastes some space. I want to try to solve the issue for all possible dynamic handling of ISA extensions at boot time. Inspired by Mark[2], this patch introduces riscv_has_extension_*() helpers, which work like static branches but are patched using alternatives, thus the metadata can be freed after patching. [1]https://lore.kernel.org/linux-riscv/20220922060958.44203-1-samuel@sholland.org/ [2]https://lore.kernel.org/linux-arm-kernel/20220912162210.3626215-8-mark.rutland@arm.com/ [3]https://lore.kernel.org/linux-riscv/20221130225614.1594256-1-heiko@sntech.de/ * b4-shazam-merge: riscv: remove riscv_isa_ext_keys[] array and related usage riscv: KVM: Switch has_svinval() to riscv_has_extension_unlikely() riscv: cpu_relax: switch to riscv_has_extension_likely() riscv: alternative: patch alternatives in the vDSO riscv: switch to relative alternative entries riscv: module: Add ADD16 and SUB16 rela types riscv: module: move find_section to module.h riscv: fpu: switch has_fpu() to riscv_has_extension_likely() riscv: introduce riscv_has_extension_[un]likely() riscv: cpufeature: extend riscv_cpufeature_patch_func to all ISA extensions riscv: hwcap: make ISA extension ids can be used in asm riscv: cpufeature: detect RISCV_ALTERNATIVES_EARLY_BOOT earlier riscv: move riscv_noncoherent_supported() out of ZICBOM probe Link: https://lore.kernel.org/r/20230128172856.3814-1-jszhang@kernel.orgSigned-off-by:
-
- 01 Feb, 2023 13 commits
-
-
Jisheng Zhang authored
All users have switched to riscv_has_extension_*, remove unused definitions, vars and related setting code. Signed-off-by:
-
Andrew Jones authored
Switch has_svinval() from static branch to the new helper riscv_has_extension_unlikely(). Signed-off-by:
Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20230128172856.3814-13-jszhang@kernel.orgSigned-off-by:
-
Jisheng Zhang authored
Switch cpu_relax() from static branch to the new helper riscv_has_extension_likely() Signed-off-by:
-
Jisheng Zhang authored
Make it possible to use alternatives in the vDSO, so that better implementations can be used if possible. Signed-off-by:
-
Jisheng Zhang authored
Instead of using absolute addresses for both the old instrucions and the alternative instructions, use offsets relative to the alt_entry values. So this not only cuts the size of the alternative entry, but also meets the prerequisite for patching alternatives in the vDSO, since absolute alternative entries are subject to dynamic relocation, which is incompatible with the vDSO building. Signed-off-by:
-
Andrew Jones authored
To prepare for 16-bit relocation types to be emitted in alternatives add support for ADD16 and SUB16. Signed-off-by:
-
Jisheng Zhang authored
Move find_section() to module.h so that the implementation can be shared by the alternatives code. This will allow us to use alternatives in the vdso. Reviewed-by:
-
Jisheng Zhang authored
Switch has_fpu() from static branch to the new helper riscv_has_extension_likely(). Signed-off-by:
-
Jisheng Zhang authored
Generally, riscv ISA extensions are fixed for any specific hardware platform, so a hart's features won't change after booting. This chacteristic makes it straightforward to use a static branch to check if a specific ISA extension is supported or not to optimize performance. However, some ISA extensions such as SVPBMT and ZICBOM are handled via. the alternative sequences. Basically, for ease of maintenance, we prefer to use static branches in C code, but recently, Samuel found that the static branch usage in cpu_relax() breaks building with CONFIG_CC_OPTIMIZE_FOR_SIZE[1]. As Samuel pointed out, "Having a static branch in cpu_relax() is problematic because that function is widely inlined, including in some quite complex functions like in the VDSO. A quick measurement shows this static branch is responsible by itself for around 40% of the jump table." Samuel's findings pointed out one of a few downsides of static branches usage in C code to handle ISA extensions detected at boot time: static branch's metadata in the __jump_table section, which is not discarded after ISA extensions are finalized, wastes some space. I want to try to solve the issue for all possible dynamic handling of ISA extensions at boot time. Inspired by Mark[2], this patch introduces riscv_has_extension_*() helpers, which work like static branches but are patched using alternatives, thus the metadata can be freed after patching. Link: https://lore.kernel.org/linux-riscv/20220922060958.44203-1-samuel@sholland.org/ [1] Link: https://lore.kernel.org/linux-arm-kernel/20220912162210.3626215-8-mark.rutland@arm.com/ [2] Signed-off-by:
-
Jisheng Zhang authored
riscv_cpufeature_patch_func() currently only scans a limited set of cpufeatures, explicitly defined with macros. Extend it to probe for all ISA extensions. Signed-off-by:
-
Jisheng Zhang authored
So that ISA extensions can be used in assembly files, convert the multi-letter RISC-V ISA extension IDs enums to macros. In order to make them visible, move the #ifndef __ASSEMBLY__ guard to a later point in the header Signed-off-by:
-
Jisheng Zhang authored
Currently riscv_cpufeature_patch_func() does nothing at the RISCV_ALTERNATIVES_EARLY_BOOT stage. Add a check to detect whether we are in this stage and exit early. This will allow us to use riscv_cpufeature_patch_func() for scanning of all ISA extensions. Signed-off-by:
-
Jisheng Zhang authored
It's a bit weird to call riscv_noncoherent_supported() each time when insmoding a module. Move the calling out of feature patch func. Signed-off-by:
-
- 31 Jan, 2023 3 commits
-
-
Palmer Dabbelt authored
Heiko Stuebner <heiko@sntech.de> says: From: Heiko Stuebner <heiko.stuebner@vrull.eu> This series still tries to allow optimized string functions for specific extensions. The last approach of using an inline base function to hold the alternative calls did cause some issues in a number of places So instead of that we're now just using an alternative j at the beginning of the generic function to jump to a separate place inside the function itself. * b4-shazam-merge: RISC-V: add zbb support to string functions RISC-V: add infrastructure to allow different str* implementations Link: https://lore.kernel.org/r/20230113212301.3534711-1-heiko@sntech.deSigned-off-by:
-
Heiko Stuebner authored
Add handling for ZBB extension and add support for using it as a variant for optimized string functions. Support for the Zbb-str-variants is limited to the GNU-assembler for now, as LLVM has not yet acquired the functionality to selectively change the arch option in assembler code. This is still under review at https://reviews.llvm.org/D123515Co-developed-by:Christoph Muellner <christoph.muellner@vrull.eu> Signed-off-by:
-
Heiko Stuebner authored
Depending on supported extensions on specific RISC-V cores, optimized str* functions might make sense. This adds basic infrastructure to allow patching the function calls via alternatives later on. The Linux kernel provides standard implementations for string functions but when architectures want to extend them, they need to provide their own. The added generic string functions are done in assembler (taken from disassembling the main-kernel functions for now) to allow us to control the used registers and extend them with optimized variants. This doesn't override the compiler's use of builtin replacements. So still first of all the compiler will select if a builtin will be better suitable i.e. for known strings. For all regular cases we will want to later select possible optimized variants and in the worst case fall back to the generic implemention added with this change. Reviewed-by:
-
- 25 Jan, 2023 3 commits
-
-
Ley Foon Tan authored
If "capacity-dmips-mhz" is present in a CPU DT node, topology_parse_cpu_capacity() will fail to allocate memory. arm64, with which this code path is shared, does not call topology_parse_cpu_capacity() until later in boot where memory allocation is available. While "capacity-dmips-mhz" is not yet a valid property on RISC-V, invalid properties should be ignored rather than cause issues. Move init_cpu_topology(), which calls topology_parse_cpu_capacity(), to a later initialization stage, to match arm64. As a side effect of this change, RISC-V is "protected" from changes to core topology code that would work on arm64 where memory allocation is safe but on RISC-V isn't. Fixes: 03f11f03 ("RISC-V: Parse cpu topology during boot.") Reviewed-by:
-
Heiko Stuebner authored
Commit b0f4c74e ("RISC-V: Fix unannoted hardirqs-on in return to userspace slow-path") renamed the do_notify_resume function to do_work_pending but did not change the prototype in signal.h Do that now, as the original function does not exist anymore. Fixes: b0f4c74e ("RISC-V: Fix unannoted hardirqs-on in return to userspace slow-path") Signed-off-by:
-
Liao Chang authored
Set kprobe at 'jalr 1140(ra)' of vfs_write results in the following crash: [ 32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170 [ 32.093115] Oops [#1] [ 32.093251] Modules linked in: [ 32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16 [ 32.093985] Hardware name: riscv-virtio,qemu (DT) [ 32.094280] epc : ksys_read+0x88/0xd6 [ 32.094855] ra : ksys_read+0xc0/0xd6 [ 32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0 [ 32.095227] gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80 [ 32.095500] t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60 [ 32.095716] s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708 [ 32.095921] a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300 [ 32.096171] a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff [ 32.096411] s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170 [ 32.096638] s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030 [ 32.096865] s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410 [ 32.097092] s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c [ 32.097317] t5 : ffffffff8000c29c t6 : ffffffff800dbc54 [ 32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d [ 32.098011] [<ffffffff801cdb72>] ksys_write+0x6c/0xd6 [ 32.098222] [<ffffffff801cdc06>] sys_write+0x2a/0x38 [ 32.098405] [<ffffffff80003c76>] ret_from_syscall+0x0/0x2 Since the rs1 and rd might be the same one, such as 'jalr 1140(ra)', hence it requires obtaining the target address from rs1 followed by updating rd. Fixes: c22b0bcb ("riscv: Add kprobes supported") Signed-off-by:
Liao Chang <liaochang1@huawei.com> Reviewed-by:
-
