Conor Dooley [Fri, 10 Feb 2023 18:59:45 +0000 (18:59 +0000)]
RISC-V: add a spin_shadow_stack declaration
The patchwork automation reported a sparse complaint that
spin_shadow_stack was not declared and should be static:
../arch/riscv/kernel/traps.c:335:15: warning: symbol 'spin_shadow_stack' was not declared. Should it be static?
However, this is used in entry.S and therefore shouldn't be static.
The same applies to the shadow_stack that this pseudo spinlock is
trying to protect, so do like its charge and add a declaration to
thread_info.h
Add HVO support for RISC-V; see commit 6be24bed9da3 ("mm: hugetlb:
introduce a new config HUGETLB_PAGE_FREE_VMEMMAP"). This patch is
similar to commit 1e63ac088f20 ("arm64: mm: hugetlb: enable
HUGETLB_PAGE_FREE_VMEMMAP for arm64"), and riscv's motivation is the
same as arm64. The current riscv was ready to enable HVO after fixup,
ref commit d33deda095d3 ("riscv/mm: hugepage's PG_dcache_clean flag
is only set in head page").
See Documentation/mm/vmemmap_dedup.rst for more details.
The HugeTLB VmemmapvOptimization (HVO) defaults to off in Kconfig.
Here is the riscv test log:
cat /proc/sys/vm/hugetlb_optimize_vmemmap
echo 8 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
mount -t hugetlbfs none test/ -o pagesize=2048k
<Try some simple hugetlb test in test dir, no problem found.>
Palmer Dabbelt [Wed, 22 Feb 2023 00:53:58 +0000 (16:53 -0800)]
Merge patch series "riscv: Dump faulting instructions in oops handler"
Björn Töpel <bjorn@kernel.org> says:
From: Björn Töpel <bjorn@rivosinc.com>
RISC-V does not dump faulting instructions in the oops handler. This
series adds "Code:" dumps to the oops output together with
scripts/decodecode support.
* b4-shazam-merge:
scripts/decodecode: Add support for RISC-V
riscv: Add instruction dump to RISC-V splats
Jisheng Zhang [Sun, 15 Jan 2023 16:28:11 +0000 (00:28 +0800)]
riscv: alternative: proceed one more instruction for auipc/jalr pair
If we patched auipc + jalr pair, we'd better proceed one more
instruction. Andrew pointed out "There's not a problem now, since
we're only adding a fixup for jal, not jalr, but we should
future-proof this and there's no reason to revisit an already fixed-up
instruction anyway."
Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Suggested-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20230115162811.3146-1-jszhang@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Palmer Dabbelt [Wed, 22 Feb 2023 00:29:10 +0000 (16:29 -0800)]
Merge patch series "riscv: improve link and support ARCH_WANT_LD_ORPHAN_WARN"
Jisheng Zhang <jszhang@kernel.org> says:
This series tries to improve link time handling of riscv:
patch1 adds the missing RUNTIME_DISCARD_EXIT as suggested by Masahiro.
Similar as other architectures such as x86, arm64 and so on, enable
ARCH_WANT_LD_ORPHAN_WARN to enable linker orphan warnings to prevent
from missing any new sections in future. So the following two patches
are preparation ones, and the last patch finally selects
ARCH_WANT_LD_ORPHAN_WARN
Mattias Nissler [Wed, 15 Feb 2023 14:48:28 +0000 (14:48 +0000)]
riscv: Avoid enabling interrupts in die()
While working on something else, I noticed that the kernel would start
accepting interrupts again after crashing in an interrupt handler. Since
the kernel is already in inconsistent state, enabling interrupts is
dangerous and opens up risk of kernel state deteriorating further.
Interrupts do get enabled via what looks like an unintended side effect of
spin_unlock_irq, so switch to the more cautious
spin_lock_irqsave/spin_unlock_irqrestore instead.
Fixes: 76d2a0493a17 ("RISC-V: Init and Halt Code") Signed-off-by: Mattias Nissler <mnissler@rivosinc.com> Reviewed-by: Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/r/20230215144828.3370316-1-mnissler@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Björn Töpel [Tue, 14 Feb 2023 16:25:15 +0000 (17:25 +0100)]
riscv, mm: Perform BPF exhandler fixup on page fault
Commit 21855cac82d3 ("riscv/mm: Prevent kernel module to access user
memory without uaccess routines") added early exits/deaths for page
faults stemming from accesses to user-space without using proper
uaccess routines (where sstatus.SUM is set).
Unfortunatly, this is too strict for some BPF programs, which relies
on BPF exhandler fixups. These BPF programs loads "BTF pointers". A
BTF pointers could either be a valid kernel pointer or NULL, but not a
userspace address.
Resolve the problem by calling the fixup handler in the early exit
path.
Fixes: 21855cac82d3 ("riscv/mm: Prevent kernel module to access user memory without uaccess routines") Signed-off-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20230214162515.184827-1-bjorn@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
This issue was exposed by 702e64550b12 ("riscv: fpu: switch has_fpu() to
riscv_has_extension_likely()"), as it is the patching in has_fpu() that
triggers the splats in Guenter's report.
Take the text_mutex before doing any code patching to satisfy lockdep.
Andrew Jones [Thu, 9 Feb 2023 12:36:36 +0000 (13:36 +0100)]
riscv: hwcap: Don't alphabetize ISA extension IDs
While the comment above the ISA extension ID definitions says
"Entries are sorted alphabetically.", this stopped being good
advice with commit d8a3d8a75206 ("riscv: hwcap: make ISA extension
ids can be used in asm"), as we now use macros instead of enums.
Reshuffling defines is error-prone, so, since they don't need to be
in any particular order, change the advice to just adding new
extensions at the bottom. Also, take the opportunity to change
spaces to tabs, merge three comments into one, and move the base
and max defines into more logical locations wrt the ID definitions.
Andy Chiu [Mon, 6 Feb 2023 09:04:40 +0000 (04:04 -0500)]
riscv: jump_label: Fixup unaligned arch_static_branch function
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.
Palmer Dabbelt [Thu, 2 Feb 2023 23:38:32 +0000 (15:38 -0800)]
RISC-V: Only provide the single-letter extensions in HWCAP
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.
Sergey Matyukevich [Sun, 29 Jan 2023 21:18:18 +0000 (00:18 +0300)]
riscv: mm: fix regression due to update_mmu_cache change
This is a partial revert of the commit 4bd1d80efb5a ("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.
Björn Töpel [Thu, 19 Jan 2023 07:47:38 +0000 (08:47 +0100)]
scripts/decodecode: Add support for RISC-V
RISC-V has some GNU disassembly quirks, e.g. it requires '-D' to
properly disassemble .2byte directives similar to Arm [1]. Further,
GNU objdump groups RISC-V instruction by 2 or 4 byte chunks, instead
doing byte-for-byte.
Add the required switches, and translate from short/word to bytes when
ARCH is "riscv".
Jisheng Zhang [Thu, 19 Jan 2023 15:54:17 +0000 (23:54 +0800)]
riscv: select ARCH_WANT_LD_ORPHAN_WARN for !XIP_KERNEL
Now, after that all the sections are explicitly described and
declared in vmlinux.lds.S, we can enable ld orphan warnings for
!XIP_KERNEL to prevent from missing any new sections in future.
Jisheng Zhang [Thu, 19 Jan 2023 15:54:16 +0000 (23:54 +0800)]
riscv: vmlinux.lds.S: explicitly catch .init.bss sections from EFI stub
When enabling linker orphan section warning, I got warnings similar as
below:
ld.lld: warning:
./drivers/firmware/efi/libstub/lib.a(efi-stub-helper.stub.o):(.init.bss)
is being placed in '.init.bss'
Catch the sections so that we can enable linker orphan section warning.
When enabling linker orphan section warning, I got warnings similar as
below:
riscv64-linux-gnu-ld: warning: orphan section `.riscv.attributes' from
`init/main.o' being placed in section `.riscv.attributes'
While I don't see any usage of .riscv.attributes sections' in kernel
now, just catch the sections so that we can enable linker orphan
section warning.
When enabling linker orphan section warning, I got warnings similar as
below:
riscv64-linux-gnu-ld: warning: orphan section `.rela.text' from
`init/main.o' being placed in section `.rela.dyn'
Use the approach similar as ARM64 does and declare it in vmlinux.lds.S
Jisheng Zhang [Thu, 19 Jan 2023 15:54:13 +0000 (23:54 +0800)]
riscv: lds: define RUNTIME_DISCARD_EXIT
riscv discards .exit.* sections at run-time but doesn't define
RUNTIME_DISCARD_EXIT. However, the .exit.* sections are still allocated
and kept even if the generic DISCARDS would discard the sections due
to missing RUNTIME_DISCARD_EXIT, because the DISCARD sits at the end of
the linker script. Add the missing RUNTIME_DISCARD_EXIT define so that
it still works if we move DISCARD up or even at the beginning of the
linker script.
Heiko Stuebner [Fri, 13 Jan 2023 21:19:55 +0000 (22:19 +0100)]
RISC-V: move some stray __RISCV_INSN_FUNCS definitions from kprobes
The __RISCV_INSN_FUNCS originally declared riscv_insn_is_* functions inside
the kprobes implementation. This got moved into a central header in
commit ec5f90877516 ("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: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu> Link: https://lore.kernel.org/r/20230113211955.3534431-1-heiko@sntech.de Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Palmer Dabbelt [Wed, 15 Feb 2023 18:57:13 +0000 (10:57 -0800)]
Merge patch series "riscv: Optimize function trace"
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
Guo Ren [Thu, 12 Jan 2023 09:05:59 +0000 (04:05 -0500)]
riscv: ftrace: Reduce the detour code size to half
Use a temporary register to reduce the size of detour code from 16 bytes to
8 bytes. The previous implementation is from 'commit afc76b8b8011 ("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.
Guo Ren [Thu, 12 Jan 2023 09:05:58 +0000 (04:05 -0500)]
riscv: ftrace: Remove wasted nops for !RISCV_ISA_C
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.
Andy Chiu [Thu, 12 Jan 2023 09:05:57 +0000 (04:05 -0500)]
riscv: ftrace: Fixup panic by disabling preemption
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: afc76b8b8011 ("riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT") Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Signed-off-by: Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20230112090603.1295340-2-guoren@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Palmer Dabbelt [Wed, 15 Feb 2023 05:33:27 +0000 (21:33 -0800)]
Merge patch series "Remove toolchain dependencies for Zicbom"
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
Conor Dooley [Sun, 8 Jan 2023 16:33:56 +0000 (16:33 +0000)]
RISC-V: remove toolchain version checks for Zicbom
Commit b8c86872d1dc ("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.
Conor Dooley [Sun, 8 Jan 2023 16:33:55 +0000 (16:33 +0000)]
RISC-V: replace cbom instructions with an insn-def
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.
Andrew Jones [Sun, 8 Jan 2023 16:33:54 +0000 (16:33 +0000)]
RISC-V: insn-def: Add I-type insn-def
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: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20230108163356.3063839-2-conor@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Palmer Dabbelt [Wed, 15 Feb 2023 03:25:10 +0000 (19:25 -0800)]
Merge patch series "dt-bindings: Add a cpu-capacity property for RISC-V"
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
Conor Dooley [Wed, 4 Jan 2023 18:05:14 +0000 (18:05 +0000)]
dt-bindings: riscv: add a capacity-dmips-mhz cpu property
Since commit 03f11f03dbfe ("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: Conor Dooley <conor.dooley@microchip.com> Reviewed-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.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Conor Dooley [Wed, 4 Jan 2023 18:05:13 +0000 (18:05 +0000)]
dt-bindings: arm: move cpu-capacity to a shared loation
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: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Ley Foon Tan <leyfoon.tan@starfivetech.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Yanteng Si <siyanteng@loongson.cn> Link: https://lore.kernel.org/r/20230104180513.1379453-2-conor@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Samuel Holland [Sun, 12 Feb 2023 02:15:33 +0000 (20:15 -0600)]
riscv: Fix Zbb alternative IDs
Commit 4bf8860760d9 ("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: 9daca9a5b9ac ("Merge patch series "riscv: improve boot time isa extensions handling"") Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Guo Ren <guoren@kernel.org> Tested-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230212021534.59121-3-samuel@sholland.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Samuel Holland [Sun, 12 Feb 2023 02:15:32 +0000 (20:15 -0600)]
riscv: Fix early alternative patching
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: 8d23e94a4433 ("riscv: switch to relative alternative entries") Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Guo Ren <guoren@kernel.org> Reviewed-by: Jisheng Zhang <jszhang@kernel.org> Tested-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230212021534.59121-2-samuel@sholland.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Conor Dooley [Mon, 19 Dec 2022 17:28:37 +0000 (17:28 +0000)]
RISC-V: re-order Kconfig selects alphanumerically
Selects should be sorted alphanumerically, and were tidied up originally
by Palmer in commit e8c7ef7d5819 ("RISC-V: Sort select statements
alphanumerically") since then, things have gotten out of order again.
Fish RMK's original script out of commit b1b3f49ce460 ("ARM: config:
sort select statements alphanumerically") and do some spring cleaning.
Palmer Dabbelt [Wed, 1 Feb 2023 07:30:07 +0000 (23:30 -0800)]
Merge patch series "riscv: improve boot time isa extensions handling"
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.
* 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
Jisheng Zhang [Sat, 28 Jan 2023 17:28:52 +0000 (01:28 +0800)]
riscv: switch to relative alternative entries
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: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230128172856.3814-10-jszhang@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Jisheng Zhang [Sat, 28 Jan 2023 17:28:48 +0000 (01:28 +0800)]
riscv: introduce riscv_has_extension_[un]likely()
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.
Jisheng Zhang [Sat, 28 Jan 2023 17:28:47 +0000 (01:28 +0800)]
riscv: cpufeature: extend riscv_cpufeature_patch_func to all ISA extensions
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 <jszhang@kernel.org> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230128172856.3814-5-jszhang@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Jisheng Zhang [Sat, 28 Jan 2023 17:28:46 +0000 (01:28 +0800)]
riscv: hwcap: make ISA extension ids can be used in asm
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
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.
Palmer Dabbelt [Tue, 31 Jan 2023 19:43:27 +0000 (11:43 -0800)]
Merge patch series "Zbb string optimizations"
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
Heiko Stuebner [Fri, 13 Jan 2023 21:23:01 +0000 (22:23 +0100)]
RISC-V: add zbb support to string functions
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/D123515
Heiko Stuebner [Fri, 13 Jan 2023 21:23:00 +0000 (22:23 +0100)]
RISC-V: add infrastructure to allow different str* implementations
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: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230113212301.3534711-2-heiko@sntech.de Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Ley Foon Tan [Thu, 5 Jan 2023 03:37:05 +0000 (11:37 +0800)]
riscv: Move call to init_cpu_topology() to later initialization stage
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.
Commit b0f4c74eadbf ("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: b0f4c74eadbf ("RISC-V: Fix unannoted hardirqs-on in return to userspace slow-path") Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230118142252.337103-1-heiko@sntech.de Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Palmer Dabbelt [Fri, 20 Jan 2023 00:39:53 +0000 (16:39 -0800)]
Merge patch series "Putting some basic order on isa extension lists"
This cleans up the ISA string handling to more closely match a version
of the ISA spec. This is visible in /proc/cpuinfo and the ordering
changes may break something in userspace, but these orderings have
changed before without issues so with any luck that's still the case.
This also adds documentation so userspace has a better idea of what is
intended when it comes to compatibility for /proc/cpuinfo, which should
help everyone as this will likely keep changing.
* b4-shazam-merge:
Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo
RISC-V: resort all extensions in consistent orders
RISC-V: clarify ISA string ordering rules in cpu.c
Masahiro Yamada [Fri, 6 Jan 2023 16:12:13 +0000 (01:12 +0900)]
riscv: fix -Wundef warning for CONFIG_RISCV_BOOT_SPINWAIT
Since commit 80b6093b55e3 ("kbuild: add -Wundef to KBUILD_CPPFLAGS
for W=1 builds"), building with W=1 detects misuse of #if.
$ make W=1 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- arch/riscv/kernel/
[snip]
AS arch/riscv/kernel/head.o
arch/riscv/kernel/head.S:329:5: warning: "CONFIG_RISCV_BOOT_SPINWAIT" is not defined, evaluates to 0 [-Wundef]
329 | #if CONFIG_RISCV_BOOT_SPINWAIT
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG_RISCV_BOOT_SPINWAIT is a bool option. #ifdef should be used.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Fixes: 2ffc48fc7071 ("RISC-V: Move spinwait booting method to its own config") Link: https://lore.kernel.org/r/20230106161213.2374093-1-masahiroy@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Conor Dooley [Fri, 6 Jan 2023 12:53:45 +0000 (12:53 +0000)]
MAINTAINERS: add an IRC entry for RISC-V
I remember being told "Just ping me on IRC" about patches, but googling
at the time was not helpful. #riscv on libera is not linux specific,
but a bunch of contributors etc do hang out there.
Add a link to the maintainers entry to help others find it in the future!
Heiko Stuebner [Thu, 5 Jan 2023 19:26:10 +0000 (20:26 +0100)]
RISC-V: fix compile error from deduplicated __ALTERNATIVE_CFG_2
On the non-assembler-side wrapping alternative-macros inside other macros
to prevent duplication of code works, as the end result will just be a
string that gets fed to the asm instruction.
In real assembler code, wrapping .macro blocks inside other .macro blocks
brings more restrictions on usage it seems and the optimization done by
commit 2ba8c7dc71c0 ("riscv: Don't duplicate __ALTERNATIVE_CFG in __ALTERNATIVE_CFG_2")
results in a compile error like:
../arch/riscv/lib/strcmp.S: Assembler messages:
../arch/riscv/lib/strcmp.S:15: Error: too many positional arguments
../arch/riscv/lib/strcmp.S:15: Error: backward ref to unknown label "886:"
../arch/riscv/lib/strcmp.S:15: Error: backward ref to unknown label "887:"
../arch/riscv/lib/strcmp.S:15: Error: backward ref to unknown label "886:"
../arch/riscv/lib/strcmp.S:15: Error: backward ref to unknown label "887:"
../arch/riscv/lib/strcmp.S:15: Error: backward ref to unknown label "886:"
../arch/riscv/lib/strcmp.S:15: Error: attempt to move .org backwards
Wrapping the variables containing assembler code in quotes solves this issue,
compilation and the code in question still works and objdump also shows sane
decompiled results of the affected code.
Fixes: 2ba8c7dc71c0 ("riscv: Don't duplicate __ALTERNATIVE_CFG in __ALTERNATIVE_CFG_2") Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20230105192610.1940841-1-heiko@sntech.de Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Conor Dooley [Mon, 5 Dec 2022 14:45:25 +0000 (14:45 +0000)]
RISC-V: resort all extensions in consistent orders
Ordering between each and every list of extensions is wildly
inconsistent. Per discussion on the lists pick the following policy:
- The array defining order in /proc/cpuinfo follows a narrow
interpretation of the ISA specifications, described in a comment
immediately presiding it.
- All other lists of extensions are sorted alphabetically.
This will hopefully allow for easier review & future additions, and
reduce conflicts between patchsets as the number of extensions grows.
Conor Dooley [Mon, 5 Dec 2022 14:45:24 +0000 (14:45 +0000)]
RISC-V: clarify ISA string ordering rules in cpu.c
While the current list of rules may have been accurate when created
it now lacks some clarity in the face of isa-manual updates. Instead of
trying to continuously align this rule-set with the one in the
specifications, change the role of this comment.
This particular comment is important, as the array it "decorates"
defines the order in which the ISA string appears to userspace in
/proc/cpuinfo.
Re-jig and strengthen the wording to provide contributors with a set
order in which to add entries & note why this particular struct needs
more attention than others.
While in the area, add some whitespace and tweak some wording for
readability's sake.
Conor Dooley [Wed, 11 Jan 2023 10:48:49 +0000 (10:48 +0000)]
RISC-V: fix incorrect type of ARCH_CANAAN_K210_DTB_SOURCE
When adding the ARCH_ symbol for the builtin K210 dtb, I erroneously
used the bool type for something that is quite obviously a string.
Unfortunately, there is no such thing as "def_string", but in this case
we can use "default" to propagate the value of
SOC_CANAAN_K210_DTB_SOURCE to ARCH_CANAAN_K210_DTB_SOURCE.
ARCH_CANAAN_K210_DTB_SOURCE is not user selectable, so using
olddefconfig etc will update ARCH_CANAAN_K210_DTB_SOURCE to reflect any
changes made to SOC_CANAAN_K210_DTB_SOURCE.
Palmer Dabbelt [Fri, 6 Jan 2023 18:31:12 +0000 (10:31 -0800)]
Merge patch series "riscv,isa fixups"
Conor Dooley <conor@kernel.org> says:
From: Conor Dooley <conor.dooley@microchip.com>
I noticed ~today~ while looking at the isa manual that I had not
accounted for another couple of edge cases with my regex. As before, I
think attempting to validate the canonical order for multiletter stuff
makes no sense - but we should totally try to avoid false-positives for
combinations that are known to be valid.
* b4-shazam-merge:
dt-bindings: riscv: fix single letter canonical order
dt-bindings: riscv: fix underscore requirement for multi-letter extensions
Conor Dooley [Mon, 5 Dec 2022 17:45:00 +0000 (17:45 +0000)]
dt-bindings: riscv: fix single letter canonical order
I used the wikipedia table for ordering extensions when updating the
pattern here in commit 299824e68bd0 ("dt-bindings: riscv: add new
riscv,isa strings for emulators").
Unfortunately that table did not match canonical order, as defined by
the RISC-V ISA Manual, which defines extension ordering in (what is
currently) Table 41, "Standard ISA extension names". Fix things up by
re-sorting v (vector) and adding p (packed-simd) & j (dynamic
languages). The e (reduced integer) and g (general) extensions are still
intentionally left out.
Conor Dooley [Mon, 5 Dec 2022 17:44:59 +0000 (17:44 +0000)]
dt-bindings: riscv: fix underscore requirement for multi-letter extensions
The RISC-V ISA Manual allows the first multi-letter extension to avoid
a leading underscore. Underscores are only required between multi-letter
extensions.
The dt-binding does not validate that a multi-letter extension is
canonically ordered, as that'd need an even worse regex than is here,
but it should not fail validation for valid ISA strings.
Allow the first multi-letter extension to appear immediately after
the single-letter extensions.
Ben Dooks [Thu, 29 Dec 2022 17:05:45 +0000 (17:05 +0000)]
riscv: uaccess: fix type of 0 variable on error in get_user()
If the get_user(x, ptr) has x as a pointer, then the setting
of (x) = 0 is going to produce the following sparse warning,
so fix this by forcing the type of 'x' when access_ok() fails.
fs/aio.c:2073:21: warning: Using plain integer as NULL pointer
Palmer Dabbelt [Thu, 29 Dec 2022 14:59:55 +0000 (06:59 -0800)]
Merge patch series "Allow calls in alternatives"
Heiko Stuebner <heiko@sntech.de> says:
From: Heiko Stuebner <heiko.stuebner@vrull.eu>
This series is split out of my work on optimizing string functions
and provides the basics to:
- actually allowing calls in alternatives
Function calls use auipc + jalr to reach those 32bit relative
addresses but when they're compiled the offset will be wrong
as alternatives live in a different section. So when the patch
gets applied the address will point to the wrong location.
So similar to arm64 the target addresses need to be updated.
This is probably also helpful for other things needing more
complex code in alternatives.
For v2 I got into some sort of cleanup spree for the general instruction
parsing that already existed. A number of places do their own
instruction parsing and I tried consolidating some of them.
Noteable, the kvm parts still do, but I had to stop somewhere :-)
* b4-shazam-merge:
RISC-V: fix auipc-jalr addresses in patched alternatives
RISC-V: add helpers for handling immediates in U-type and I-type pairs
RISC-V: add rd reg parsing to insn.h header
RISC-V: add U-type imm parsing to insn.h header
RISC-V: kprobes: use central defined funct3 constants
RISC-V: rename parse_asm.h to insn.h
RISC-V: Move riscv_insn_is_* macros into a common header
RISC-V: add auipc elements to parse_asm header
RISC-V: add ebreak instructions to definitions
RISC-V: detach funct-values from their offset
RISC-V: add prefix to all constants/macros in parse_asm.h
RISC-V: fix funct4 definition for c.jalr in parse_asm.h
Heiko Stuebner [Fri, 23 Dec 2022 22:13:31 +0000 (23:13 +0100)]
RISC-V: add helpers for handling immediates in U-type and I-type pairs
Used together U-type and I-type instructions can for example be used to
generate bigger jumps (i.e. in auipc+jalr pairs) by splitting the value
into an upper immediate (i.e. auipc) and a 12bit immediate (i.e. jalr).
Due to both immediates being considered signed this creates some corner
cases, so add some helper to prevent this from getting duplicated in
different places.
Heiko Stuebner [Fri, 23 Dec 2022 22:13:29 +0000 (23:13 +0100)]
RISC-V: add U-type imm parsing to insn.h header
Similar to other existing types, allow extracting the immediate
for a U-type instruction.
U-type immediates are special in that regard, that the value
in the instruction in bits [31:12] already represents the same
bits of the immediate, so no shifting is required.
U-type immediates are for example used in the auipc instruction,
so these constants make it easier to parse such instructions.
Heiko Stuebner [Fri, 23 Dec 2022 22:13:27 +0000 (23:13 +0100)]
RISC-V: rename parse_asm.h to insn.h
The current parse_asm header should become a more centralized place
for everything concerning parsing and constructing instructions.
We already have a header insn-def.h similar to aarch64, so rename
parse_asm.h to insn.h (again similar to aarch64) to show that it's
meant for more than simple instruction parsing.
Heiko Stuebner [Fri, 23 Dec 2022 22:13:26 +0000 (23:13 +0100)]
RISC-V: Move riscv_insn_is_* macros into a common header
Right now the riscv kernel has (at least) two independent sets
of functions to check if an encoded instruction is of a specific
type. One in kgdb and one kprobes simulate-insn code.
More parts of the kernel will probably need this in the future,
so instead of allowing this duplication to go on further,
move macros that do the function declaration in a common header,
similar to at least aarch64.
Heiko Stuebner [Fri, 23 Dec 2022 22:13:25 +0000 (23:13 +0100)]
RISC-V: add auipc elements to parse_asm header
Instruction parsing should not be done in individual code, but instead
supported by central
Right now kgdb and kprobes parse instructions and at least kprobes (and
the upcoming auipc+jalr alternative fixer-function) need the auipc
instruction.
Heiko Stuebner [Fri, 23 Dec 2022 22:13:23 +0000 (23:13 +0100)]
RISC-V: detach funct-values from their offset
Rather than defining funct3, funct4, etc values pre-shifted to their
target-position in an instruction, define the values themselves and
only shift them where needed.
This allows using these funct-values in other places as well, for example
when decoding functions.
At the same time also reduces the use of magic numbers, one would need
a spec manual to understand.
Palmer Dabbelt [Wed, 28 Dec 2022 19:01:31 +0000 (11:01 -0800)]
Merge tag 'soc2arch-immutable' of git://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into for-next
SOC_FOO to ARCH_FOO conversion for RISC-V
RISC-V is an outlier in using SOC_FOO rather than ARCH_FOO for
vendors/micro-archs. SOC_FOO may make more sense (I personally prefer
it), but the rest of the "world" uses ARCH_FOO. That'd be fine, with
with an increasing number of existing SoC vendors moving to RISC-V,
unifying our symbol names with the expectations of the rest of the world
makes sense.
Folks did not seem keen on changing the world (and they can't really be
blamed for that) so convert RISC-V over to match.
Add some ARCH_FOO stubs alongside the existing SOC_FOO ones, which will
be removed once all users of SOC_FOO have been converted*, and convert
the DT bits of RISC-V kbuild over to the new symbols.
* It may be best to wait until after the next LTS to remove the SOC_FOO
ones, for the sake of external users.
* tag 'soc2arch-immutable' of git://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
RISC-V: stop directly selecting drivers for SOC_CANAAN
RISC-V: stop selecting SiFive clock and serial drivers directly
RISC-V: stop selecting the PolarFire SoC clock driver
RISC-V: kbuild: convert all use of SOC_FOO to ARCH_FOO
RISC-V: kconfig.socs: convert usage of SOC_CANAAN to ARCH_CANAAN
RISC-V: introduce ARCH_FOO kconfig aliases for SOC_FOO symbols
Conor Dooley [Sun, 20 Nov 2022 20:59:41 +0000 (20:59 +0000)]
RISC-V: introduce ARCH_FOO kconfig aliases for SOC_FOO symbols
To facilitate a transfer from SOC_FOO to ARCH_FOO, over a release cycle,
introduce some aliases so that drivers etc that use the SOC_FOO symbols
can be converted.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
To me, the most straight-forward conversion looks like so:
- this patch is applied in week 2 of the merge window, to avoid
any conflicts with the Renesas tree
- all users of the SOC_ variants can be converted over a release cycle
(or more) & no trees need to merge an immutable branch.
- we convert defconfig etc over after all users are converted
- doing it over at least one release cycle means that `make oldconfig`
will keep people's configs working as they upgrade
- any new SoC families added uses ARCH_FOO
Conor Dooley [Sun, 20 Nov 2022 21:34:44 +0000 (21:34 +0000)]
RISC-V: kbuild: convert all use of SOC_FOO to ARCH_FOO
Convert all non user visible use of SOC_FOO symbols to their ARCH_FOO
variants. The canaan DTs are an outlier in that they're gated at the
directory and the file level. Drop the directory level gating while we
are swapping the symbol names over.
Steven Rostedt (Google) [Tue, 20 Dec 2022 18:45:19 +0000 (13:45 -0500)]
treewide: Convert del_timer*() to timer_shutdown*()
Due to several bugs caused by timers being re-armed after they are
shutdown and just before they are freed, a new state of timers was added
called "shutdown". After a timer is set to this state, then it can no
longer be re-armed.
The following script was run to find all the trivial locations where
del_timer() or del_timer_sync() is called in the same function that the
object holding the timer is freed. It also ignores any locations where
the timer->function is modified between the del_timer*() and the free(),
as that is not considered a "trivial" case.
This was created by using a coccinelle script and the following
commands:
Linus Torvalds [Fri, 23 Dec 2022 22:44:08 +0000 (14:44 -0800)]
Merge tag 'spi-fix-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fix from Mark Brown:
"One driver specific change here which handles the case where a SPI
device for some reason tries to change the bus speed during a message
on fsl_spi hardware, this should be very unusual"
* tag 'spi-fix-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: fsl_spi: Don't change speed while chipselect is active
Linus Torvalds [Fri, 23 Dec 2022 22:38:00 +0000 (14:38 -0800)]
Merge tag 'regulator-fix-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"Two core fixes here, one for a long standing race which some Qualcomm
systems have started triggering with their UFS driver and another
fixing a problem with supply lookup introduced by the fixes for devm
related use after free issues that were introduced in this merge
window"
* tag 'regulator-fix-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: fix deadlock on regulator enable
regulator: core: Fix resolve supply lookup issue
Linus Torvalds [Fri, 23 Dec 2022 20:00:24 +0000 (12:00 -0800)]
Merge tag 'hardening-v6.2-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull kernel hardening fixes from Kees Cook:
- Fix CFI failure with KASAN (Sami Tolvanen)
- Fix LKDTM + CFI under GCC 7 and 8 (Kristina Martsenko)
- Limit CONFIG_ZERO_CALL_USED_REGS to Clang > 15.0.6 (Nathan
Chancellor)
- Ignore "contents" argument in LoadPin's LSM hook handling
- Fix paste-o in /sys/kernel/warn_count API docs
- Use READ_ONCE() consistently for oops/warn limit reading
* tag 'hardening-v6.2-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
cfi: Fix CFI failure with KASAN
exit: Use READ_ONCE() for all oops/warn limit reads
security: Restrict CONFIG_ZERO_CALL_USED_REGS to gcc or clang > 15.0.6
lkdtm: cfi: Make PAC test work with GCC 7 and 8
docs: Fix path paste-o for /sys/kernel/warn_count
LoadPin: Ignore the "contents" argument of the LSM hooks
projects / users / willy / xarray.git / log