struct drm_syncobj_eventfd was documented, but
DRM_IOCTL_SYNCOBJ_EVENTFD was not. This prevents references to this
define from being properly linkified in docs.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Michel Dänzer <michel.daenzer@mailbox.org>
Link: https://patch.msgid.link/20260327171812.128290-1-contact@emersion.fr
Clippy fires two clippy::precedence warnings on the manual
byte-shifting expression:
warning: operator precedence can trip the unwary
--> drivers/gpu/nova-core/vbios.rs:511:17
|
511 | / u32::from(data[29]) << 24
512 | | | u32::from(data[28]) << 16
513 | | | u32::from(data[27]) << 8
| |______________________________________________^
Clear the warnings by replacing manual byte-shifting with
u32::from_le_bytes(). Using from_le_bytes() is also a tiny code
improvement, because it uses less code and is clearer about the intent.
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Link: https://patch.msgid.link/20260404212831.78971-2-jhubbard@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The current implementation does not actually set the default values for
the fields in the bitfield.
Fixes: 3fa145bef5 ("gpu: nova-core: register: generate correct `Default` implementation")
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260401-fix-bitfield-v2-1-2fa68c98114a@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Commit a88831502c ("gpu: nova-core: falcon: use dma::Coherent")
dropped the nova-local `DmaObject` device memory type for the
kernel-global `Coherent` one.
This switch had a side-effect: `DmaObject` always aligned the requested
size to `PAGE_SIZE`, and also reported that adjusted size when queried.
`Coherent`, on the other hand, does page-align allocation sizes but only
allows CPU access on the exact size provided by the caller.
This change runs into a limitation of falcon DMA copies, namely that DMA
accesses are done on blocks of exactly 256 bytes. If the provided data
does not have a length that is a multiple of 256, `dma_wr` returns
an error.
It was expected that all firmwares would present the proper adjusted
size, but this is not the case at least on my GA107:
NovaCore 0000:08:00.0: DMA transfer goes beyond range of DMA object
NovaCore 0000:08:00.0: Failed to load FWSEC firmware: EINVAL
NovaCore 0000:08:00.0: probe with driver NovaCore failed with error -22
Fix this by padding the `Coherent`'s size to `MEM_BLOCK_ALIGNMENT` (i.e.
256) when allocating it and filling it with zeroes, before copying the
firmware on top of it.
Fixes: a88831502c ("gpu: nova-core: falcon: use dma::Coherent")
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260405-falcon-dma-roundup-v2-1-4af5b2ff9c16@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
`driver_read_area` and `driver_write_area` are internal methods that
return slices containing the area of the command queue buffer that the
driver has exclusive read or write access, respectively.
While their returned value is correct and safe to use, internally they
temporarily create a reference to the whole command-buffer slice,
including GSP-owned regions. These regions can change without notice,
and thus creating a slice to them, even if never accessed, is undefined
behavior.
Fix this by making these methods create slices to valid regions only.
Fixes: 75f6b1de81 ("gpu: nova-core: gsp: Add GSP command queue bindings and handling")
Reported-by: Danilo Krummrich <dakr@kernel.org>
Closes: https://lore.kernel.org/all/DH47AVPEKN06.3BERUSJIB4M1R@kernel.org/
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260404-cmdq-ub-fix-v5-1-53d21f4752f5@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Commit 6a859f1a19 ("powerpc: unify two CONFIG_POWERPC64_CPU entries
in the same choice block") removed the only occurrence of this tricky
use case.
Disallow this pattern in choice_check_sanity() and revert commit
4d46b5b623 ("kconfig: fix infinite loop in sym_calc_choice()").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20260330115736.1559962-1-masahiroy@kernel.org
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Signed-off-by: Nicolas Schier <nsc@kernel.org>
The debug information part of the "Absolute filenames" section in the
reproducible builds document only mentions providing
'-fdebug-prefix-map' to KCFLAGS but it needs to be provided to KAFLAGS
as well since debug information has been generated for assembly files
for a long time.
Additionally, mention that the build directory may also appear as an
absolute path in the debug information (via DW_AT_comp_dir), so it needs
to be overridden via '-fdebug-prefix-map' as well.
Reported-by: Alexander Coffin <alex@cyberialabs.net>
Closes: https://lore.kernel.org/b8dfe7035d19fd611b9be55ee3145fdb@purelymail.com/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20260313-kbuild-docs-repro-builds-fdebug-prefix-map-updates-v1-1-3aeeef7fa710@kernel.org
Signed-off-by: Nicolas Schier <nsc@kernel.org>
On MIPS the checksyscalls.sh script may be executed multiple times.
Currently these multiple executions are executed on each build as kbuild
see that the commands have changed each time.
Use a dedicated stamp file for each different invocation to avoid the
spurious executions.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://patch.msgid.link/20260402-kbuild-missing-syscalls-v3-3-6641be1de2db@weissschuh.net
Signed-off-by: Nicolas Schier <nsc@kernel.org>
Currently checksyscalls.sh is unconditionally executed during each build.
Most of these executions are unnecessary.
Only run checksyscalls.sh if one of its inputs have changed.
This new logic does not work for the multiple invocations done for MIPS.
The effect is that checksyscalls.sh is still executed unconditionally.
However this is not worse than before.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://patch.msgid.link/20260402-kbuild-missing-syscalls-v3-2-6641be1de2db@weissschuh.net
Signed-off-by: Nicolas Schier <nsc@kernel.org>
An upcoming patch will need to reuse this path.
Move it into a reusable variable.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://patch.msgid.link/20260402-kbuild-missing-syscalls-v3-1-6641be1de2db@weissschuh.net
Signed-off-by: Nicolas Schier <nsc@kernel.org>
As we are missing ID_AA64PFR2_EL1.GCIE from the kernel feature set,
userspace cannot write ID_AA64PFR2_EL1 with GCIE set, even if we are
on a GICv5 host.
Add the required field description.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://patch.msgid.link/20260401170017.369529-1-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
if de goes negative right under us, there's nothing to prevent inode
getting freed just as we call coda_flag_inode(). We are not holding
->d_lock, so it's not impossible. Not going to be reproducible on
bare hardware unless it's a realtime config, but it could happen on KVM.
Trivial to fix - just hold rcu_read_lock() over that loop.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
d_really_is_negative(dentry) is a check for d_inode(dentry) being NULL;
rechecking that is pointless (and no, it can't race - the caller is holding
->d_lock, so ->d_inode is stable)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
XIP has a history of being broken for long periods of time. In 2023, it was
broken for 18 months before getting fixed [1]. In 2024 it was 4 months [2].
And now it is broken again since commit a44fb57221 ("riscv: Add runtime
constant support"), 10 months ago.
These are clear signs that XIP feature is not being used.
I occasionally looked after XIP, but mostly because I was bored and had
nothing better to do.
Remove XIP support. Revert is possible if someone shows up complaining.
Link: https://lore.kernel.org/linux-riscv/20231212-customary-hardcover-e19462bf8e75@wendy/ [1]
Link: https://lore.kernel.org/linux-riscv/20240526110104.470429-1-namcao@linutronix.de/ [2]
Signed-off-by: Nam Cao <namcao@linutronix.de>
Cc: Frederik Haxel <haxel@fzi.de>
Cc: Vitaly Wool <vitaly.wool@konsulko.com>
Reviewed-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260202115403.2119218-1-namcao@linutronix.de
[pjw@kernel.org: updated to apply]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Scalar misaligned access probe and vector misaligned access probe share
very similar code. Split out this similar part from scalar probe into
compare_unaligned_access(), which will be reused for vector probe in a
follow-up commit.
Signed-off-by: Nam Cao <namcao@linutronix.de>
Link: https://patch.msgid.link/3695f77279d473eead8ed6210d97c941321cd4f1.1770830596.git.namcao@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Byte cycle measurement and word cycle measurement of scalar misaligned
access are very similar. Split these parts out into a common
measure_cycles() function to avoid duplication.
This function will also be reused for vector misaligned access probe in a
follow-up commit.
Signed-off-by: Nam Cao <namcao@linutronix.de>
Link: https://patch.msgid.link/50d0598e45acc56c95176e52fbbe56e1f4becc84.1770830596.git.namcao@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
check_unaligned_access_speed_all_cpus() is more complicated than it should
be:
- It uses on_each_cpu() to probe unaligned memory access on all CPUs but
excludes CPU0 with a check in the callback function. So an IPI to CPU0
is wasted.
- Probing on CPU0 is done with smp_call_on_cpu(), which is not as fast as
on_each_cpu().
The reason for this design is because the probe is timed with jiffies.
Therefore on_each_cpu() excludes CPU0 because that CPU needs to tend to
jiffies.
Instead, replace jiffies usage with ktime_get_mono_fast_ns(). With jiffies
out of the way, on_each_cpu() can be used for all CPUs and
smp_call_on_cpu() can be dropped.
To make ktime_get_mono_fast_ns() usable, move this probe to late_initcall.
Anything after clocksource's fs_initcall works, but avoid depending on
clocksource staying at fs_initcall.
The choice of probe time is now 8000000 ns, which is the same as before (2
jiffies) for riscv defconfig. This is excessive for the CPUs I have, and
probably should be reduced; but that's a different discussion.
Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Nam Cao <namcao@linutronix.de>
Link: https://patch.msgid.link/9b9a20affe2e4f5c380926ceb885a47e20a59395.1770830596.git.namcao@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Add an assembly implementation of strrchr() for RISC-V.
This implementation minimizes instruction count and avoids unnecessary
memory access to the stack. The performance benefits are most visible
on small workloads (1-16 bytes) where the architectural savings in
function overhead outweigh the execution time of the scan loop.
Benchmark results (QEMU TCG, rv64):
Length | Original (MB/s) | Optimized (MB/s) | Improvement
-------|-----------------|------------------|------------
1 B | 20 | 21 | +5.0%
7 B | 111 | 120 | +8.1%
16 B | 189 | 199 | +5.3%
512 B | 361 | 382 | +5.8%
4096 B | 388 | 391 | +0.8%
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Tested-by: Joel Stanley <joel@jms.id.au>
Link: https://patch.msgid.link/20260130025018.172925-9-jiangfeng@kylinos.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Add an assembly implementation of strchr() for RISC-V.
By eliminating stack frame management (prologue/epilogue) and optimizing
the function entries, the assembly version provides significant relative
gains for short strings where the fixed overhead of the C function is
most prominent. As string length increases, performance converges with
the generic C implementation.
Benchmark results (QEMU TCG, rv64):
Length | Original (MB/s) | Optimized (MB/s) | Improvement
-------|-----------------|------------------|------------
1 B | 21 | 22 | +4.8%
7 B | 113 | 121 | +7.1%
16 B | 195 | 202 | +3.6%
512 B | 376 | 389 | +3.5%
4096 B | 394 | 393 | -0.3%
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Tested-by: Joel Stanley <joel@jms.id.au>
Link: https://patch.msgid.link/20260130025018.172925-8-jiangfeng@kylinos.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Add an optimized strnlen() implementation for RISC-V. This version
includes a generic optimization and a Zbb-powered optimization using
the 'orc.b' instruction, derived from the strlen() implementation.
Benchmark results (QEMU TCG, rv64):
Length | Original (MB/s) | Optimized (MB/s) | Improvement
-------|-----------------|------------------|------------
16 B | 179 | 309 | +72.6%
512 B | 347 | 1562 | +350.1%
4096 B | 356 | 1878 | +427.5%
Suggested-by: Qingfang Deng <dqfext@gmail.com>
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Link: https://patch.msgid.link/20260130025018.172925-7-jiangfeng@kylinos.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Extend the string benchmarking suite to include strnlen(), strchr(),
and strrchr().
For character search functions strchr() and strrchr(), the benchmark
targets the NUL character. This ensures the entire string is scanned,
providing a consistent measure of full-length processing efficiency
comparable to strlen().
Suggested-by: Andy Shevchenko <andy@kernel.org>
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Acked-by: Andy Shevchenko <andy@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://patch.msgid.link/20260130025018.172925-6-jiangfeng@kylinos.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Introduce a benchmarking framework to the string_kunit test suite to
measure the execution efficiency of string functions.
The implementation is inspired by crc_benchmark(), measuring throughput
(MB/s) and latency (ns/call) across a range of string lengths. It
includes a warm-up phase, disables preemption during measurement, and
uses a fixed seed for reproducible results.
This framework allows for comparing different implementations (e.g.,
generic C vs. architecture-optimized assembly) within the KUnit
environment.
Initially, provide a benchmark for strlen().
Suggested-by: Andy Shevchenko <andy@kernel.org>
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://patch.msgid.link/20260130025018.172925-5-jiangfeng@kylinos.cn
[pjw@kernel.org: fixed a checkpatch issue]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Add a KUnit test for strrchr() to verify correctness across
different string lengths and memory alignments. Use vmalloc()
to place the NUL character at the page boundary to ensure
over-reads are detected.
Suggested-by: Kees Cook <kees@kernel.org>
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://patch.msgid.link/20260130025018.172925-4-jiangfeng@kylinos.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Add a KUnit test for strnlen() to verify correctness across
different string lengths and memory alignments. Use vmalloc()
to place the NUL character at the page boundary to ensure
over-reads are detected.
Suggested-by: Andy Shevchenko <andy@kernel.org>
Suggested-by: Kees Cook <kees@kernel.org>
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://patch.msgid.link/20260130025018.172925-3-jiangfeng@kylinos.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Add a KUnit test for strlen() to verify correctness across
different string lengths and memory alignments. Use vmalloc()
to place the NUL character at the page boundary to ensure
over-reads are detected.
Suggested-by: Kees Cook <kees@kernel.org>
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://patch.msgid.link/20260130025018.172925-2-jiangfeng@kylinos.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
The vdso_cfi build process copies source files (*.c, *.S) from the main
vdso directory to the build directory. Without a .gitignore file, these
copied files appear as untracked files in git status, cluttering the
working directory.
Add a .gitignore file to exclude:
- Copied source files (*.c, *.S)
- Temporary build files (vdso.lds, *.tmp, vdso-syms.S)
- While preserving vdso-cfi.S which is the original entry point
This follows the same pattern used in the main vdso directory
and keeps the working directory clean.
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
Link: https://patch.msgid.link/20260320021850.1877-3-cp0613@linux.alibaba.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
When building VDSO with CFI support, source files are copied from the main
VDSO directory to the CFI build directory as part of the build process.
However, these copied source files were not removed during 'make clean',
leaving temporary files in the build directory.
Add the clean-files variable to ensure that these copied .c and .S files
are properly cleaned up. The notdir() function is used to strip the path
prefix, as clean-files expects relative file names without directory
components.
This ensures the build directory is left in a clean state after make clean.
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
Link: https://patch.msgid.link/20260320021850.1877-2-cp0613@linux.alibaba.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
RISC-V has implemented pte_pgprot() and selects GENERIC_IOREMAP,
which provides a generic ioremap_prot() implementation. Enable
HAVE_IOREMAP_PROT to activate generic_access_phys() support, which
is useful for debugging (e.g., accessing /dev/mem via gdb).
Also update the architecture support documentation accordingly.
Signed-off-by: Yufeng Wang <wangyufeng@kylinos.cn>
Link: https://patch.msgid.link/20260306112734.108186-1-r4o5m6e8o@163.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
ACPI 6.6 is required for RISC-V as it introduces RISC-V specific
tables such as RHCT (RISC-V Hart Capabilities Table) and
RIMT (RISC-V I/O Mapping Table).
Update the FADT revision check from 6.5 to 6.6 and remove
the TODO comment since ACPI 6.6 has been officially released.
Signed-off-by: Yufeng Wang <wangyufeng@kylinos.cn>
Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Yao Zi <me@ziyao.cc>
Link: https://patch.msgid.link/20260305091433.83983-1-r4o5m6e8o@163.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Add support for handling hardware error traps (exception code 19)
in the RISC-V architecture. The changes include:
- Add do_trap_hardware_error function declaration in asm-prototypes.h
- Add hardware error trap vector entry in entry.S exception vector table
- Implement do_trap_hardware_error handler in traps.c that generates
SIGBUS with BUS_MCEERR_AR for hardware errors
This enables proper handling of hardware error exceptions that may occur
in RISC-V systems, providing appropriate error reporting and signal
generation for user space processes.
Signed-off-by: Rui Qi <qirui.001@bytedance.com>
Link: https://patch.msgid.link/20260202094200.53735-1-qirui.001@bytedance.com
[pjw@kernel.org: clean up commit message slightly]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
SoC people may send many parameters to configure the drivers via kernel
command line. If COMMAND_LINE_SIZE is not enough, they may go through
unexpected error.
To avoid the potential pain, we had better increase COMMAND_LINE_SIZE.
Signed-off-by: Austin Kim <austin.kim@lge.com>
Link: https://patch.msgid.link/aW3gFmOlA/Z4kmfJ@adminpc-PowerEdge-R7525
Signed-off-by: Paul Walmsley <pjw@kernel.org>
The cpu-hotplug.c only is built when CONFIG_HOTPLUG_CPU is defined,
it is not needed to check HOTPLUG_CPU in this file.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://patch.msgid.link/20260304033403.238012-2-hui.wang@canonical.com
[pjw@kernel.org: removed extra whitespace at EOF]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
In the arch/riscv/Kconfig, the HOTPLUG_CPU depends on SMP, hence if
the HOTPLUG_CPU is defined, the SMP has to be defined, it is not
necessary to check SMP here.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://patch.msgid.link/20260304033403.238012-1-hui.wang@canonical.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
The following options are required by the kdump crash utility for RISC-V
based vmcore file:
- kaslr: If the vmcore is generated from a KASLR-enabled Linux kernel,
the KASLR offset is required for the crash utility to load
the vmcore. Without the proper kaslr option, the crash utility
fails to load the vmcore file.
- satp: The exact root page table address helps determine the correct base
PGD address.
With this patch, RISC-V VMCOREINFO ELF notes now include both kaslr
and satp information.
Signed-off-by: Austin Kim <austin.kim@lge.com>
Link: https://patch.msgid.link/aYwKUE3ZzN7/ZY/A@adminpc-PowerEdge-R7525
Signed-off-by: Paul Walmsley <pjw@kernel.org>
The kaslr_offset() function is a simple accessor that returns
kernel_map.virt_offset. This commit change also ensures that kaslr_offset()
is consistently available across various kernel configurations without
requiring explicit linkage to mm/init.c.
Signed-off-by: Austin Kim <austin.kim@lge.com>
Link: https://patch.msgid.link/aYwJ76yHaMbbQVJA@adminpc-PowerEdge-R7525
Signed-off-by: Paul Walmsley <pjw@kernel.org>
local_flush_icache_all() only flushes and synchronizes the *instruction*
cache, not the data cache. Since RISC-V does have a cbo.flush
instruction for data cache flush, clarify the comment to avoid
confusion.
Fixes: 58661a30f1 ("riscv: Flush the instruction cache during SMP bringup")
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://patch.msgid.link/20260204-riscv-smp-comment-update-2026-01-v1-2-8b77aa181530@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Commit f1a0a376ca ("sched/core: Initialize the idle task with
preemption disabled") removed a call to preempt_disable(), but not the
associated comment. Remove the outdated comment.
Fixes: f1a0a376ca ("sched/core: Initialize the idle task with preemption disabled")
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://patch.msgid.link/20260204-riscv-smp-comment-update-2026-01-v1-1-8b77aa181530@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Per Linus' comments requesting the replacement of "INDIR_BR_LP" in the
indirect branch tracking prctl()s with something more readable, and
suggesting the use of the speculation control prctl()s as an exemplar,
reimplement the prctl()s and related constants that control per-task
forward-edge control flow integrity.
This primarily involves two changes. First, the prctls are
restructured to resemble the style of the speculative execution
workaround control prctls PR_{GET,SET}_SPECULATION_CTRL, to make them
easier to extend in the future. Second, the "indir_br_lp" abbrevation
is expanded to "branch_landing_pads" to be less telegraphic. The
kselftest and documentation is adjusted accordingly.
Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/
Cc: Deepak Gupta <debug@rivosinc.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Similar to the recent change to expand "LP" to "branch landing pad",
let's expand "SS" in the ptrace uapi macros to "shadow stack" as well.
This aligns with the existing prctl() arguments, which use the
expanded "shadow stack" names, rather than just the abbreviation.
Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/
Cc: Deepak Gupta <debug@rivosinc.com>
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Per Linus' comments about the unreadability of abbreviations such as
"indir_br_lp", rename the three prctl() implementation functions to be more
explicit. This involves renaming "indir_br_lp_status" in the function
names to "branch_landing_pad_state".
While here, add _prctl_ into the function names, following the
speculation control prctl implementation functions.
Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/
Cc: Deepak Gupta <debug@rivosinc.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Paul Walmsley <pjw@kernel.org>
