aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2022-08-12wireguard: selftests: set CONFIG_NONPORTABLE on riscv32Jason A. Donenfeld1-0/+1
When the CONFIG_PORTABLE/CONFIG_NONPORTABLE switches were added, various configs were updated, but the wireguard config was forgotten about. This leads to unbootable test kernels, causing CI fails. Add CONFIG_NONPORTABLE=y to the wireguard test suite configuration for riscv32. Fixes: 44c1e84a38a0 ("RISC-V: Add CONFIG_{NON,}PORTABLE") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220809145757.83673-1-Jason@zx2c4.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-12RISC-V: KVM: Support sstc extensionAtish Patra4-7/+153
Sstc extension allows the guest to program the vstimecmp CSR directly instead of making an SBI call to the hypervisor to program the next event. The timer interrupt is also directly injected to the guest by the hardware in this case. To maintain backward compatibility, the hypervisors also update the vstimecmp in an SBI set_time call if the hardware supports it. Thus, the older kernels in guest also take advantage of the sstc extension. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Atish Patra <atishp@rivosinc.com> Acked-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/all/CAAhSdy2mb6wyqy0NAn9BcTWKMYEc0Z4zU3s3j7oNqBz6eDQ9sg@mail.gmail.com/ Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Improve SBI definitionsAtish Patra1-2/+16
Fixed few typos and bit fields not aligned with the spec. Define other related macros that will be useful in the future. Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20220711174632.4186047-6-atishp@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Move counter info definition to sbi header fileAtish Patra2-14/+14
Counter info encoding format is defined by the SBI specificaiton. KVM implementation of SBI PMU extension will also leverage this definition. Move the definition to common sbi header file from the sbi pmu driver. Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20220711174632.4186047-5-atishp@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Fix SBI PMU calls for RV32Atish Patra1-0/+10
Some of the SBI PMU calls does not pass 64bit arguments correctly and not under RV32 compile time flags. Currently, this doesn't create any incorrect results as RV64 ignores any value in the additional register and qemu doesn't support raw events. Fix those SBI calls in order to set correct values for RV32. Fixes: e9991434596f ("RISC-V: Add perf platform driver based on SBI PMU extension") Signed-off-by: Atish Patra <atishp@rivosinc.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220711174632.4186047-4-atishp@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Update user page mapping only once during startAtish Patra2-1/+1
Currently, riscv_pmu_event_set_period updates the userpage mapping. However, the caller of riscv_pmu_event_set_period should update the userpage mapping because the counter can not be updated/started from set_period function in counter overflow path. Invoke the perf_event_update_userpage at the caller so that it doesn't get invoked twice during counter start path. Fixes: f5bfa23f576f ("RISC-V: Add a perf core library for pmu drivers") Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Guo Ren <guoren@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220711174632.4186047-3-atishp@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Fix counter restart during overflow for RV32Atish Patra1-0/+5
Pass the upper half of the initial value of the counter correctly for RV32. Fixes: 4905ec2fb7e6 ("RISC-V: Add sscofpmf extension support") Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Guo Ren <guoren@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220711174632.4186047-2-atishp@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Prefer sstc extension if availableAtish Patra1-1/+24
RISC-V ISA has sstc extension which allows updating the next clock event via a CSR (stimecmp) instead of an SBI call. This should happen dynamically if sstc extension is available. Otherwise, it will fallback to SBI call to maintain backward compatibility. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20220722165047.519994-4-atishp@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Enable sstc extension parsing from DTAtish Patra3-0/+3
The ISA extension framework now allows parsing any multi-letter ISA extension. Enable that for sstc extension. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20220722165047.519994-3-atishp@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Add SSTC extension CSR detailsAtish Patra1-0/+5
This patch just introduces the required CSR fields related to the SSTC extension. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20220722165047.519994-2-atishp@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11riscv:uprobe fix SR_SPIE set/clear handlingYipeng Zou1-6/+0
In riscv the process of uprobe going to clear spie before exec the origin insn,and set spie after that.But When access the page which origin insn has been placed a page fault may happen and irq was disabled in arch_uprobe_pre_xol function,It cause a WARN as follows. There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol. We can just remove it. [ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488 [ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work [ 31.684929] preempt_count: 0, expected: 0 [ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G [ 31.686542] Hardware name: riscv-virtio,qemu (DT) [ 31.686797] Call Trace: [ 31.687053] [<ffffffff80006442>] dump_backtrace+0x30/0x38 [ 31.687699] [<ffffffff80812118>] show_stack+0x40/0x4c [ 31.688141] [<ffffffff8081817a>] dump_stack_lvl+0x44/0x5c [ 31.688396] [<ffffffff808181aa>] dump_stack+0x18/0x20 [ 31.688653] [<ffffffff8003e454>] __might_resched+0x114/0x122 [ 31.688948] [<ffffffff8003e4b2>] __might_sleep+0x50/0x7a [ 31.689435] [<ffffffff80822676>] down_read+0x30/0x130 [ 31.689728] [<ffffffff8000b650>] do_page_fault+0x166/x446 [ 31.689997] [<ffffffff80003c0c>] ret_from_exception+0x0/0xc Fixes: 74784081aac8 ("riscv: Add uprobes supported") Signed-off-by: Yipeng Zou <zouyipeng@huawei.com> Reviewed-by: Guo Ren <guoren@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220721065820.245755-1-zouyipeng@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11dt-bindings: riscv: fix SiFive l2-cache's cache-setsConor Dooley1-1/+5
Fix device tree schema validation error messages for the SiFive Unmatched: ' cache-sets:0:0: 1024 was expected'. The existing bindings allow for just 1024 cache-sets but the fu740 on Unmatched the has 2048 cache-sets. The ISA itself permits any arbitrary power of two, however this is not supported by dt-schema. The RTL for the IP, to which the number of cache-sets is a tunable parameter, has been released publicly so speculatively adding a small number of "reasonable" values seems unwise also. Instead, as the binding only supports two distinct controllers: add 2048 and explicitly lock it to the fu740's l2 cache while limiting 1024 to the l2 cache on the fu540. Fixes: af951c3a113b ("dt-bindings: riscv: Update l2 cache DT documentation to add support for SiFive FU740") Reported-by: Atul Khare <atulkhare@rivosinc.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220803185359.942928-1-mail@conchuod.ie Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11riscv: ensure cpu_ops_sbi is declaredConor Dooley2-0/+3
Sparse complains that cpu_ops_sbi is used undeclared: arch/riscv/kernel/cpu_ops_sbi.c:17:29: warning: symbol 'cpu_ops_sbi' was not declared. Should it be static? Fix the warning by adding cpu_ops_sbi to cpu_ops_sbi.h & including that where used. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20220714080235.3853374-1-conor.dooley@microchip.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: cpu_ops_spinwait.c should include head.hBen Dooks1-0/+2
Running sparse shows cpu_ops_spinwait.c is missing two definitions found in head.h, so include it to stop the following warnings: arch/riscv/kernel/cpu_ops_spinwait.c:15:6: warning: symbol '__cpu_spinwait_stack_pointer' was not declared. Should it be static? arch/riscv/kernel/cpu_ops_spinwait.c:16:6: warning: symbol '__cpu_spinwait_task_pointer' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@sifive.com> Link: https://lore.kernel.org/r/20220713215306.94675-1-ben.dooks@sifive.com Fixes: c78f94f35cf6 ("RISC-V: Use __cpu_up_stack/task_pointer only for spinwait method") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Declare cpu_ops_spinwait in <asm/cpu_ops.h>Ben Dooks2-3/+2
The cpu_ops_spinwait is used in a couple of places in arch/riscv and is causing a sparse warning due to no declaration. Add this to <asm/cpu_ops.h> with the others to fix the following: arch/riscv/kernel/cpu_ops_spinwait.c:16:29: warning: symbol 'cpu_ops_spinwait' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@sifive.com> Link: https://lore.kernel.org/r/20220714071811.187491-1-ben.dooks@sifive.com [Palmer: Drop the extern from cpu_ops.c] Fixes: 2ffc48fc7071 ("RISC-V: Move spinwait booting method to its own config") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11riscv: dts: starfive: correct number of external interruptsMark Kettenis1-1/+1
The PLIC integrated on the Vic_U7_Core integrated on the StarFive JH7100 SoC actually supports 133 external interrupts. 127 of these are exposed to the outside world; the remainder are used by other devices that are part of the core-complex such as the L2 cache controller. But all 133 interrupts are external interrupts as far as the PLIC is concerned. Fix the property so that the driver can manage these additional interrupts, which is important since the interrupts for the L2 cache controller are enabled by default. Fixes: ec85362fb121 ("RISC-V: Add initial StarFive JH7100 device tree") Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220707185529.19509-1-kettenis@openbsd.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11riscv: dts: sifive unmatched: Add PWM controlled LEDsEmil Renner Berthing1-0/+42
This adds the two PWM controlled LEDs to the HiFive Unmatched device tree. D12 is just a regular green diode, but D2 is an RGB diode with 3 PWM inputs controlling the three different colours. Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Pavel Machek <pavel@ucw.cz> Tested-by: Ron Economos <re@w6rz.net> Link: https://lore.kernel.org/r/20220705210143.315151-5-emil.renner.berthing@canonical.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11riscv/purgatory: Omit use of bin2cMasahiro Yamada5-9/+17
The .incbin assembler directive is much faster than bin2c + $(CC). Do similar refactoring as in commit 4c0f032d4963 ("s390/purgatory: Omit use of bin2c"). Please note the .quad directive matches to size_t in C (both 8 byte) because the purgatory is compiled only for the 64-bit kernel. (KEXEC_FILE depends on 64BIT). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20220625223438.835408-2-masahiroy@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11riscv/purgatory: hard-code obj-y in MakefileMasahiro Yamada1-1/+1
The purgatory/ directory is entirely guarded in arch/riscv/Kbuild. CONFIG_ARCH_HAS_KEXEC_PURGATORY is bool type. $(CONFIG_ARCH_HAS_KEXEC_PURGATORY) is always 'y' when Kbuild visits this Makefile for building. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20220625223438.835408-1-masahiroy@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Add modules to virtual kernel memory layout dumpXianting Tian1-0/+4
Modules always live before the kernel, MODULES_END is fixed but MODULES_VADDR isn't fixed, it depends on the kernel size. Let's add it to virtual kernel memory layout dump. As MODULES is only defined for CONFIG_64BIT, so we dump it when CONFIG_64BIT=y. eg, MODULES_VADDR - MODULES_END 0xffffffff01133000 - 0xffffffff80000000 Reviewed-by: Guo Ren <guoren@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> Link: https://lore.kernel.org/r/20220811074150.3020189-5-xianting.tian@linux.alibaba.com Cc: stable@vger.kernel.org Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear mapping") Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11riscv: traps_misaligned: do not duplicate stringifyKrzysztof Kozlowski1-5/+3
Use existing stringify macro from the kernel headers. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20220623112905.253157-1-krzysztof.kozlowski@linaro.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Fixup schedule out issue in machine_crash_shutdown()Xianting Tian1-4/+22
Current task of executing crash kexec will be schedule out when panic is triggered by RCU Stall, as it needs to wait rcu completion. It lead to inability to enter the crash system. The implementation of machine_crash_shutdown() is non-standard for RISC-V according to other Arch's implementation(eg, x86, arm64), we need to send IPI to stop secondary harts. [224521.877268] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [224521.883471] rcu: 0-...0: (3 GPs behind) idle=cfa/0/0x1 softirq=3968793/3968793 fqs=2495 [224521.891742] (detected by 2, t=5255 jiffies, g=60855593, q=328) [224521.897754] Task dump for CPU 0: [224521.901074] task:swapper/0 state:R running task stack: 0 pid: 0 ppid: 0 flags:0x00000008 [224521.911090] Call Trace: [224521.913638] [<ffffffe000c432de>] __schedule+0x208/0x5ea [224521.918957] Kernel panic - not syncing: RCU Stall [224521.923773] bad: scheduling from the idle thread! [224521.928571] CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Tainted: G O 5.10.113-yocto-standard #1 [224521.938658] Call Trace: [224521.941200] [<ffffffe00020395c>] walk_stackframe+0x0/0xaa [224521.946689] [<ffffffe000c34f8e>] show_stack+0x32/0x3e [224521.951830] [<ffffffe000c39020>] dump_stack_lvl+0x7e/0xa2 [224521.957317] [<ffffffe000c39058>] dump_stack+0x14/0x1c [224521.962459] [<ffffffe000243884>] dequeue_task_idle+0x2c/0x40 [224521.968207] [<ffffffe000c434f4>] __schedule+0x41e/0x5ea [224521.973520] [<ffffffe000c43826>] schedule+0x34/0xe4 [224521.978487] [<ffffffe000c46cae>] schedule_timeout+0xc6/0x170 [224521.984234] [<ffffffe000c4491e>] wait_for_completion+0x98/0xf2 [224521.990157] [<ffffffe00026d9e2>] __wait_rcu_gp+0x148/0x14a [224521.995733] [<ffffffe0002761c4>] synchronize_rcu+0x5c/0x66 [224522.001307] [<ffffffe00026f1a6>] rcu_sync_enter+0x54/0xe6 [224522.006795] [<ffffffe00025a436>] percpu_down_write+0x32/0x11c [224522.012629] [<ffffffe000c4266a>] _cpu_down+0x92/0x21a [224522.017771] [<ffffffe000219a0a>] smp_shutdown_nonboot_cpus+0x90/0x118 [224522.024299] [<ffffffe00020701e>] machine_crash_shutdown+0x30/0x4a [224522.030483] [<ffffffe00029a3f8>] __crash_kexec+0x62/0xa6 [224522.035884] [<ffffffe000c3515e>] panic+0xfa/0x2b6 [224522.040678] [<ffffffe0002772be>] rcu_sched_clock_irq+0xc26/0xcb8 [224522.046774] [<ffffffe00027fc7a>] update_process_times+0x62/0x8a [224522.052785] [<ffffffe00028d522>] tick_sched_timer+0x9e/0x102 [224522.058533] [<ffffffe000280c3a>] __hrtimer_run_queues+0x16a/0x318 [224522.064716] [<ffffffe0002812ec>] hrtimer_interrupt+0xd4/0x228 [224522.070551] [<ffffffe0009a69b6>] riscv_timer_interrupt+0x3c/0x48 [224522.076646] [<ffffffe000268f8c>] handle_percpu_devid_irq+0xb0/0x24c [224522.083004] [<ffffffe00026428e>] __handle_domain_irq+0xa8/0x122 [224522.089014] [<ffffffe00062f954>] riscv_intc_irq+0x38/0x60 [224522.094501] [<ffffffe000201bd4>] ret_from_exception+0x0/0xc [224522.100161] [<ffffffe000c42146>] rcu_eqs_enter.constprop.0+0x8c/0xb8 With the patch, it can enter crash system when RCU Stall occur. Fixes: e53d28180d4d ("RISC-V: Add kdump support") Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> Link: https://lore.kernel.org/r/20220811074150.3020189-4-xianting.tian@linux.alibaba.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: Fixup get incorrect user mode PC for kernel mode regsXianting Tian1-1/+1
When use 'echo c > /proc/sysrq-trigger' to trigger kdump, riscv_crash_save_regs() will be called to save regs for vmcore, we found "epc" value 00ffffffa5537400 is not a valid kernel virtual address, but is a user virtual address. Other regs(eg, ra, sp, gp...) are correct kernel virtual address. Actually 0x00ffffffb0dd9400 is the user mode PC of 'PID: 113 Comm: sh', which is saved in the task's stack. [ 21.201701] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #45 [ 21.201979] Hardware name: riscv-virtio,qemu (DT) [ 21.202160] epc : 00ffffffa5537400 ra : ffffffff80088640 sp : ff20000010333b90 [ 21.202435] gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be7c [ 21.202707] t1 : 0720072007200720 t2 : 30203a7375746174 s0 : ff20000010333cf0 [ 21.202973] s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001 [ 21.203243] a2 : 0000000000000010 a3 : 0000000000000000 a4 : 28c8f0aeffea4e00 [ 21.203519] a5 : 28c8f0aeffea4e00 a6 : 0000000000000009 a7 : ffffffff8035c9b8 [ 21.203794] s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98 [ 21.204062] s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468 [ 21.204331] s8 : 00ffffffef451410 s9 : 0000000000000007 s10: 00aaaaaac0510700 [ 21.204606] s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00 [ 21.204876] t5 : ff60000001218000 t6 : ff200000103338b8 [ 21.205079] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008 With the incorrect PC, the backtrace showed by crash tool as below, the first stack frame is abnormal, crash> bt PID: 113 TASK: ff60000002269600 CPU: 0 COMMAND: "sh" #0 [ff2000001039bb90] __efistub_.Ldebug_info0 at 00ffffffa5537400 <-- Abnormal #1 [ff2000001039bcf0] panic at ffffffff806578ba #2 [ff2000001039bd50] sysrq_reset_seq_param_set at ffffffff8038c030 #3 [ff2000001039bda0] __handle_sysrq at ffffffff8038c5f8 #4 [ff2000001039be00] write_sysrq_trigger at ffffffff8038cad8 #5 [ff2000001039be20] proc_reg_write at ffffffff801b7edc #6 [ff2000001039be40] vfs_write at ffffffff80152ba6 #7 [ff2000001039be80] ksys_write at ffffffff80152ece #8 [ff2000001039bed0] sys_write at ffffffff80152f46 With the patch, we can get current kernel mode PC, the output as below, [ 17.607658] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #42 [ 17.607937] Hardware name: riscv-virtio,qemu (DT) [ 17.608150] epc : ffffffff800078f8 ra : ffffffff8008862c sp : ff20000010333b90 [ 17.608441] gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be68 [ 17.608741] t1 : 0720072007200720 t2 : 666666666666663c s0 : ff20000010333cf0 [ 17.609025] s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001 [ 17.609320] a2 : 0000000000000010 a3 : 0000000000000000 a4 : 0000000000000000 [ 17.609601] a5 : ff60000001c78000 a6 : 000000000000003c a7 : ffffffff8035c9a4 [ 17.609894] s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98 [ 17.610186] s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468 [ 17.610469] s8 : 00ffffffca281410 s9 : 0000000000000007 s10: 00aaaaaab5bb6700 [ 17.610755] s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00 [ 17.611041] t5 : ff60000001218000 t6 : ff20000010333988 [ 17.611255] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008 With the correct PC, the backtrace showed by crash tool as below, crash> bt PID: 113 TASK: ff6000000226c200 CPU: 0 COMMAND: "sh" #0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8 <--- Normal #1 [ff20000010333cf0] panic at ffffffff806578c6 #2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c #3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604 #4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4 #5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8 #6 [ff20000010333e40] vfs_write at ffffffff80152bb2 #7 [ff20000010333e80] ksys_write at ffffffff80152eda #8 [ff20000010333ed0] sys_write at ffffffff80152f52 Fixes: e53d28180d4d ("RISC-V: Add kdump support") Co-developed-by: Guo Ren <guoren@kernel.org> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> Link: https://lore.kernel.org/r/20220811074150.3020189-3-xianting.tian@linux.alibaba.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11RISC-V: kexec: Fixup use of smp_processor_id() in preemptible contextXianting Tian1-1/+1
Use __smp_processor_id() to avoid check the preemption context when CONFIG_DEBUG_PREEMPT enabled, as we will enter crash kernel and no return. Without the patch, [ 103.781044] sysrq: Trigger a crash [ 103.784625] Kernel panic - not syncing: sysrq triggered crash [ 103.837634] CPU1: off [ 103.889668] CPU2: off [ 103.933479] CPU3: off [ 103.939424] Starting crashdump kernel... [ 103.943442] BUG: using smp_processor_id() in preemptible [00000000] code: sh/346 [ 103.950884] caller is debug_smp_processor_id+0x1c/0x26 [ 103.956051] CPU: 0 PID: 346 Comm: sh Kdump: loaded Not tainted 5.10.113-00002-gce03f03bf4ec-dirty #149 [ 103.965355] Call Trace: [ 103.967805] [<ffffffe00020372a>] walk_stackframe+0x0/0xa2 [ 103.973206] [<ffffffe000bcf1f4>] show_stack+0x32/0x3e [ 103.978258] [<ffffffe000bd382a>] dump_stack_lvl+0x72/0x8e [ 103.983655] [<ffffffe000bd385a>] dump_stack+0x14/0x1c [ 103.988705] [<ffffffe000bdc8fe>] check_preemption_disabled+0x9e/0xaa [ 103.995057] [<ffffffe000bdc926>] debug_smp_processor_id+0x1c/0x26 [ 104.001150] [<ffffffe000206c64>] machine_kexec+0x22/0xd0 [ 104.006463] [<ffffffe000291a7e>] __crash_kexec+0x6a/0xa4 [ 104.011774] [<ffffffe000bcf3fa>] panic+0xfc/0x2b0 [ 104.016480] [<ffffffe000656ca4>] sysrq_reset_seq_param_set+0x0/0x70 [ 104.022745] [<ffffffe000657310>] __handle_sysrq+0x8c/0x154 [ 104.028229] [<ffffffe0006577e8>] write_sysrq_trigger+0x5a/0x6a [ 104.034061] [<ffffffe0003d90e0>] proc_reg_write+0x58/0xd4 [ 104.039459] [<ffffffe00036cff4>] vfs_write+0x7e/0x254 [ 104.044509] [<ffffffe00036d2f6>] ksys_write+0x58/0xbe [ 104.049558] [<ffffffe00036d36a>] sys_write+0xe/0x16 [ 104.054434] [<ffffffe000201b9a>] ret_from_syscall+0x0/0x2 [ 104.067863] Will call new kernel at ecc00000 from hart id 0 [ 104.074939] FDT image at fc5ee000 [ 104.079523] Bye... With the patch we can got clear output, [ 67.740553] sysrq: Trigger a crash [ 67.744166] Kernel panic - not syncing: sysrq triggered crash [ 67.809123] CPU1: off [ 67.865210] CPU2: off [ 67.909075] CPU3: off [ 67.919123] Starting crashdump kernel... [ 67.924900] Will call new kernel at ecc00000 from hart id 0 [ 67.932045] FDT image at fc5ee000 [ 67.935560] Bye... Fixes: 0e105f1d0037 ("riscv: use hart id instead of cpu id on machine_kexec") Reviewed-by: Guo Ren <guoren@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Atish Patra <atishp@rivosinc.com> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> Link: https://lore.kernel.org/r/20220811074150.3020189-2-xianting.tian@linux.alibaba.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-11arch/riscv: add Zihintpause supportDao Lu5-3/+29
Implement support for the ZiHintPause extension. The PAUSE instruction is a HINT that indicates the current hart’s rate of instruction retirement should be temporarily reduced or paused. Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Dao Lu <daolu@rivosinc.com> [Palmer: Some minor merge conflicts.] Link: https://lore.kernel.org/all/20220620201530.3929352-1-daolu@rivosinc.com/ Link: https://lore.kernel.org/all/20220811053356.17375-1-palmer@rivosinc.com/ Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-10riscv: lib: uaccess: fix CSR_STATUS SR_SUM bitChen Lifu1-2/+2
Since commit 5d8544e2d007 ("RISC-V: Generic library routines and assembly") and commit ebcbd75e3962 ("riscv: Fix the bug in memory access fixup code"), if __clear_user and __copy_user return from an fixup branch, CSR_STATUS SR_SUM bit will be set, it is a vulnerability, so that S-mode memory accesses to pages that are accessible by U-mode will success. Disable S-mode access to U-mode memory should clear SR_SUM bit. Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly") Fixes: ebcbd75e3962 ("riscv: Fix the bug in memory access fixup code") Signed-off-by: Chen Lifu <chenlifu@huawei.com> Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk> Link: https://lore.kernel.org/r/20220615014714.1650349-1-chenlifu@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-06Revert "iommu/dma: Add config for PCI SAC address trick"Linus Torvalds2-27/+1
This reverts commit 4bf7fda4dce22214c70c49960b1b6438e6260b67. It turns out that it was hopelessly naive to think that this would work, considering that we've always done this. The first machine I actually tested this on broke at bootup, getting to Reached target cryptsetup.target - Local Encrypted Volumes. and then hanging. It's unclear what actually fails, since there's a lot else going on around that time (eg amdgpu probing also happens around that same time, but it could be some other random init thing that didn't complete earlier and just caused the boot to hang at that point). The expectations that we should default to some unsafe and untested mode seems entirely unfounded, and the belief that this wouldn't affect modern systems is clearly entirely false. The machine in question is about two years old, so it's not exactly shiny, but it's also not some dusty old museum piece PDP-11 in a closet. Cc: Robin Murphy <robin.murphy@arm.com> Cc: Christoph Hellwig <hch@lst.de> Cc: John Garry <john.garry@huawei.com> Cc: Joerg Roedel <jroedel@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-04rv: Unlock on error path in rv_unregister_reactor()Dan Carpenter1-2/+4
Unlock the "rv_interface_lock" mutex before returning. Link: https://lkml.kernel.org/r/YuvYzNfGMgV+PIhd@kili Fixes: 04acadcb4453 ("rv: Add runtime reactors interface") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2022-08-04s390/dasd: Establish DMA alignmentEric Farman2-0/+2
linux-next commit bf8d08532bc1 ("iomap: add support for dma aligned direct-io") changes the alignment requirement to come from the block device rather than the block size, and the default alignment requirement is 512-byte boundaries. Since DASD I/O has page alignments for IDAW/TIDAW requests, let's override this value to restore the expected behavior. Make this change for both ECKD and DIAG disciplines, as they both would fall into this category. Leave FBA alone, since it is always comprised of 512-byte blocks. Signed-off-by: Eric Farman <farman@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Link: https://lore.kernel.org/r/20220804213926.3361574-3-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-08-04s390/dasd: drop unexpected word 'for' in commentsJiang Jian1-1/+1
there is an unexpected word 'for' in the comments that need to be dropped file - drivers/s390/block/dasd.c line - 1728 /* check for for attention message */ changed to: /* check for attention message */ Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com> Link: https://lore.kernel.org/r/20220623102114.33249-1-jiangjian@cdjrlc.com Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Link: https://lore.kernel.org/r/20220804213926.3361574-2-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-08-04dm verity: have verify_wq use WQ_HIGHPRI if "try_verify_in_tasklet"Mike Snitzer1-1/+11
Allow verify_wq to preempt softirq since verification in tasklet will fall-back to using it for error handling (or if the bufio cache doesn't have required hashes). Suggested-by: Nathan Huckleberry <nhuck@google.com> Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-08-04drm/amd/amdgpu: fix build failure due to implicit declarationSudip Mukherjee1-0/+1
The builds for alpha and mips allmodconfig fails with the error: drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:534:23: error: implicit declaration of function 'vmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:534:21: error: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion] drivers/gpu/drm/amd/amdgpu/psp_v13_0.c:545:33: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration] Add the header file for vmalloc and vfree. Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-04usb: cdns3: Don't use priv_dev uninitialized in cdns3_gadget_ep_enable()Nathan Chancellor1-4/+8
Clang warns: drivers/usb/cdns3/cdns3-gadget.c:2290:11: error: variable 'priv_dev' is uninitialized when used here [-Werror,-Wuninitialized] dev_dbg(priv_dev->dev, "usbss: invalid parameters\n"); ^~~~~~~~ include/linux/dev_printk.h:155:18: note: expanded from macro 'dev_dbg' dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__) ^~~ include/linux/dynamic_debug.h:167:7: note: expanded from macro 'dynamic_dev_dbg' dev, fmt, ##__VA_ARGS__) ^~~ include/linux/dynamic_debug.h:152:56: note: expanded from macro '_dynamic_func_call' __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__) ^~~~~~~~~~~ include/linux/dynamic_debug.h:134:15: note: expanded from macro '__dynamic_func_call' func(&id, ##__VA_ARGS__); \ ^~~~~~~~~~~ drivers/usb/cdns3/cdns3-gadget.c:2278:31: note: initialize the variable 'priv_dev' to silence this warning struct cdns3_device *priv_dev; ^ = NULL 1 error generated. The priv_dev assignment was moved below the if statement to avoid potentially dereferencing ep before it was checked but priv_dev is used in the dev_dbg() call. To fix this, move the priv_dev and comp_desc assignments back to their original spot and hoist the ep check above those assignments with a call to pr_debug() instead of dev_dbg(). Fixes: c3ffc9c4ca44 ("usb: cdns3: change place of 'priv_ep' assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable()") Link: https://github.com/ClangBuiltLinux/linux/issues/1680 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-04dm verity: remove WQ_CPU_INTENSIVE flag since using WQ_UNBOUNDMike Snitzer1-1/+1
The documentation [1] says that WQ_CPU_INTENSIVE is "meaningless" for unbound wq. So remove WQ_CPU_INTENSIVE from the verify_wq allocation. 1. https://www.kernel.org/doc/html/latest/core-api/workqueue.html#flags Suggested-by: Maksym Planeta <mplaneta@os.inf.tu-dresden.de> Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-08-04dm verity: only copy bvec_iter in verity_verify_io if in_taskletMike Snitzer1-9/+16
Avoid extra bvec_iter copy unless it is needed to allow retrying verification, that failed from a tasklet, from a workqueue. Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-08-04dm verity: optimize verity_verify_io if FEC not configuredMike Snitzer1-1/+8
Only declare and copy bvec_iter if CONFIG_DM_VERITY_FEC is defined and FEC enabled for the verity device. Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-08-04dm verity: conditionally enable branching for "try_verify_in_tasklet"Mike Snitzer1-5/+14
Use jump_label to limit the need for branching unless the optional "try_verify_in_tasklet" feature is used. Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-08-04dm bufio: conditionally enable branching for DM_BUFIO_CLIENT_NO_SLEEPMike Snitzer1-4/+11
Use jump_label to limit the need for branching unless the optional DM_BUFIO_CLIENT_NO_SLEEP is used. Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-08-04dm verity: allow optional args to alter primary args handlingMike Snitzer1-8/+24
The previous commit ("dm verity: Add optional "try_verify_in_tasklet" feature") imposed that CRYPTO_ALG_ASYNC mask be used even if the optional "try_verify_in_tasklet" feature was not specified. This was because verity_parse_opt_args() was called after handling the primary args (due to it having data dependencies on having first parsed all primary args). Enhance verity_ctr() so that simple optional args, that don't have a data dependency on primary args parsing, can alter how the primary args are handled. In practice this means verity_parse_opt_args() gets called twice. First with the new 'only_modifier_opts' arg set to true, then again with it set to false _after_ parsing all primary args. This allows the v->use_tasklet flag to be properly set and then used when verity_ctr() parses the primary args and then calls crypto_alloc_ahash() with CRYPTO_ALG_ASYNC conditionally set. Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-08-04dm verity: Add optional "try_verify_in_tasklet" featureNathan Huckleberry2-18/+91
Using tasklets for disk verification can reduce IO latency. When there are accelerated hash instructions it is often better to compute the hash immediately using a tasklet rather than deferring verification to a work-queue. This reduces time spent waiting to schedule work-queue jobs, but requires spending slightly more time in interrupt context. If the dm-bufio cache does not have the required hashes we fallback to the work-queue implementation. FEC is only possible using work-queue because code to support the FEC feature may sleep. The following shows a speed comparison of random reads on a dm-verity device. The dm-verity device uses a 1G ramdisk for data and a 1G ramdisk for hashes. One test was run using tasklets and one test was run using the existing work-queue solution. Both tests were run when the dm-bufio cache was hot. The tasklet implementation performs significantly better since there is no time spent waiting for work-queue jobs to be scheduled. READ: bw=181MiB/s (190MB/s), 181MiB/s-181MiB/s (190MB/s-190MB/s), io=512MiB (537MB), run=2827-2827msec READ: bw=23.6MiB/s (24.8MB/s), 23.6MiB/s-23.6MiB/s (24.8MB/s-24.8MB/s), io=512MiB (537MB), run=21688-21688msec Signed-off-by: Nathan Huckleberry <nhuck@google.com> Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-08-04drm/amd/display: restore code for plane with no modifiersDave Airlie1-0/+3
When this file was split in commit 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes") this chunk seemed to get dropped. Linus noticed on this rx580 and I've reproduced on FIJI which makes sense as these are pre-modifier GPUs. With this applied, I get gdm back. Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes") Signed-off-by: Dave Airlie <airlied@redhat.com> Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-03riscv: implement cache-management errata for T-Head SoCsHeiko Stuebner3-5/+74
The T-Head C906 and C910 implement a scheme for handling cache operations different from the generic Zicbom extension. Add an errata for it next to the generic dma coherency ops. Reviewed-by: Samuel Holland <samuel@sholland.org> Tested-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Guo Ren <guoren@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20220706231536.2041855-5-heiko@sntech.de Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-03tpm: Add check for Failure mode for TPM2 modulesMårten Lindahl1-0/+6
In commit 0aa698787aa2 ("tpm: Add Upgrade/Reduced mode support for TPM2 modules") it was said that: "If the TPM is in Failure mode, it will successfully respond to both tpm2_do_selftest() and tpm2_startup() calls. Although, will fail to answer to tpm2_get_cc_attrs_tbl(). Use this fact to conclude that TPM is in Failure mode." But a check was never added in the commit when calling tpm2_get_cc_attrs_tbl() to conclude that the TPM is in Failure mode. This commit corrects this by adding a check. Fixes: 0aa698787aa2 ("tpm: Add Upgrade/Reduced mode support for TPM2 modules") Cc: stable@vger.kernel.org # v5.17+ Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-08-03tpm: eventlog: Fix section mismatch for DEBUG_SECTION_MISMATCHHuacai Chen1-1/+1
If DEBUG_SECTION_MISMATCH enabled, __calc_tpm2_event_size() will not be inlined, this cause section mismatch like this: WARNING: modpost: vmlinux.o(.text.unlikely+0xe30c): Section mismatch in reference from the variable L0 to the function .init.text:early_ioremap() The function L0() references the function __init early_memremap(). This is often because L0 lacks a __init annotation or the annotation of early_ioremap is wrong. Fix it by using __always_inline instead of inline for the called-once function __calc_tpm2_event_size(). Fixes: 44038bc514a2 ("tpm: Abstract crypto agile event size calculations") Cc: stable@vger.kernel.org # v5.3 Reported-by: WANG Xuerui <git@xen0n.name> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-08-03tpm: fix platform_no_drv_owner.cocci warningYang Li1-1/+0
Eliminate the following coccicheck warning: ./drivers/char/tpm/tpm_tis_i2c.c:379:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-08-03KEYS: asymmetric: enforce SM2 signature use pkey algoTianjia Zhang1-2/+5
The signature verification of SM2 needs to add the Za value and recalculate sig->digest, which requires the detection of the pkey_algo in public_key_verify_signature(). As Eric Biggers said, the pkey_algo field in sig is attacker-controlled and should be use pkey->pkey_algo instead of sig->pkey_algo, and secondly, if sig->pkey_algo is NULL, it will also cause signature verification failure. The software_key_determine_akcipher() already forces the algorithms are matched, so the SM3 algorithm is enforced in the SM2 signature, although this has been checked, we still avoid using any algorithm information in the signature as input. Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification") Reported-by: Eric Biggers <ebiggers@google.com> Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-08-03pkcs7: support EC-RDSA/streebog in SignerInfoElvira Khabirova1-0/+11
Allow using EC-RDSA/streebog in pkcs7 certificates in a similar way to how it's done in the x509 parser. This is needed e.g. for loading kernel modules signed with EC-RDSA. Signed-off-by: Elvira Khabirova <e.khabirova@omp.ru> Reviewed-by: Vitaly Chikunov <vt@altlinux.org> Reviewed-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-08-03pkcs7: parser support SM2 and SM3 algorithms combinationTianjia Zhang1-0/+7
Support parsing the message signature of the SM2 and SM3 algorithm combination. This group of algorithms has been well supported. One of the main users is module signature verification. Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: Vitaly Chikunov <vt@altlinux.org> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-08-03sign-file: Fix confusing error messagesTianjia Zhang1-1/+1
When an error occurs, use errx() instead of err() to display the error message, because openssl has its own error record. When an error occurs, errno will not be changed, while err() displays the errno error message. It will cause confusion. For example, when CMS_add1_signer() fails, the following message will appear: sign-file: CMS_add1_signer: Success errx() ignores errno and does not cause such issue. Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-08-03X.509: Support parsing certificate using SM2 algorithmTianjia Zhang1-0/+3
The SM2-with-SM3 certificate generated by latest openssl no longer reuses the OID_id_ecPublicKey, but directly uses OID_sm2. This patch supports this type of x509 certificate parsing. Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.