Merge tag 'riscv-mw2-6.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/alexghiti/linux into for-next
riscv patches for 6.15-rc1, part 2
* A bunch of fixes:
- 2 fixes in the purgatory code which prevented kexec to work
- Workaround an issue with gcc-15
* tag 'riscv-mw2-6.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/alexghiti/linux:
riscv: Add norvc after .option arch in runtime const
riscv: Make sure toolchain supports zba before using zba instructions
riscv/purgatory: 4B align purgatory_start
riscv/kexec_file: Handle R_RISCV_64 in purgatory relocator
selftests: riscv: fix v_exec_initval_nolibc.c
riscv: Fix hugetlb retrieval of number of ptes in case of !present pte
riscv: print hartid on bringup
dt-bindings: riscv: document vector crypto requirements
dt-bindings: riscv: add vector sub-extension dependencies
dt-bindings: riscv: d requires f
RISC-V: add f & d extension validation checks
RISC-V: add vector crypto extension validation checks
RISC-V: add vector extension validation checks
Charlie Jenkins [Mon, 31 Mar 2025 18:45:24 +0000 (11:45 -0700)]
riscv: Add norvc after .option arch in runtime const
.option arch clobbers .option norvc. Prevent gas from emitting
compressed instructions in the runtime const alternative blocks by
setting .option norvc after .option arch. This issue starts appearing on
gcc 15, which adds zca to the march.
Björn Töpel [Fri, 28 Mar 2025 08:53:11 +0000 (09:53 +0100)]
riscv/purgatory: 4B align purgatory_start
When a crashkernel is launched on RISC-V, the entry to purgatory is
done by trapping via the stvec CSR. From riscv_kexec_norelocate():
| ...
| /*
| * Switch to physical addressing
| * This will also trigger a jump to CSR_STVEC
| * which in this case is the address of the new
| * kernel.
| */
| csrw CSR_STVEC, a2
| csrw CSR_SATP, zero
stvec requires that the address is 4B aligned, which was not the case,
e.g.:
Yao Zi [Wed, 26 Mar 2025 05:14:46 +0000 (05:14 +0000)]
riscv/kexec_file: Handle R_RISCV_64 in purgatory relocator
Commit 58ff537109ac ("riscv: Omit optimized string routines when
using KASAN") introduced calls to EXPORT_SYMBOL() in assembly string
routines, which result in R_RISCV_64 relocations against
.export_symbol section. As these rountines are reused by RISC-V
purgatory and our relocator doesn't recognize these relocations, this
fails kexec-file-load with dmesg like
Let's support R_RISCV_64 relocation to fix kexec on 64-bit RISC-V.
32-bit variant isn't covered since KEXEC_FILE and KEXEC_PURGATORY isn't
available.
Fixes: 58ff537109ac ("riscv: Omit optimized string routines when using KASAN") Signed-off-by: Yao Zi <ziyao@disroot.org> Tested-by: Björn Töpel <bjorn@rivosinc.com> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20250326051445.55131-2-ziyao@disroot.org Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Merge patch series "Add some validation for vector, vector crypto and fp stuff"
Conor Dooley <conor@kernel.org> says:
From: Conor Dooley <conor.dooley@microchip.com>
Yo,
This series is partly leveraging Clement's work adding a validate
callback in the extension detection code so that things like checking
for whether a vector crypto extension is usable can be done like:
has_extension(<vector crypto>)
rather than
has_vector() && has_extension(<vector crypto>)
which Eric pointed out was a poor design some months ago.
The rest of this is adding some requirements to the bindings that
prevent combinations of extensions disallowed by the ISA.
There's a bunch of over-long lines in here, but I thought that the
over-long lines were clearer than breaking them up.
Cheers,
Conor.
* patches from https://lore.kernel.org/r/20250312-abide-pancreas-3576b8c44d2c@spud:
dt-bindings: riscv: document vector crypto requirements
dt-bindings: riscv: add vector sub-extension dependencies
dt-bindings: riscv: d requires f
RISC-V: add f & d extension validation checks
RISC-V: add vector crypto extension validation checks
RISC-V: add vector extension validation checks
Ignacio Encinas [Thu, 6 Mar 2025 19:49:27 +0000 (20:49 +0100)]
selftests: riscv: fix v_exec_initval_nolibc.c
Vector registers are zero initialized by the kernel. Stop accepting
"all ones" as a clean value.
Note that this was not working as expected given that
value == 0xff
can be assumed to be always false by the compiler as value's range is
[-128, 127]. Both GCC (-Wtype-limits) and clang
(-Wtautological-constant-out-of-range-compare) warn about this.
Alexandre Ghiti [Mon, 17 Mar 2025 07:25:51 +0000 (08:25 +0100)]
riscv: Fix hugetlb retrieval of number of ptes in case of !present pte
Ryan sent a fix [1] for arm64 that applies to riscv too: in some hugetlb
functions, we must not use the pte value to get the size of a mapping
because the pte may not be present.
So use the already present size parameter for huge_pte_clear() and the
newly introduced size parameter for huge_ptep_get_and_clear(). And make
sure to gather A/D bits only on present ptes.
Yunhui Cui [Mon, 3 Mar 2025 08:34:24 +0000 (16:34 +0800)]
riscv: print hartid on bringup
Firmware randomly releases cores, so CPU numbers don't linearly map
to hartids. When the system has an exception, we care more about hartids.
Adding "dyndbg="file smpboot.c +p" loglevel=8" to the cmdline can output
the hartid.
Charlie Jenkins [Mon, 31 Mar 2025 18:45:24 +0000 (11:45 -0700)]
riscv: Add norvc after .option arch in runtime const
.option arch clobbers .option norvc. Prevent gas from emitting
compressed instructions in the runtime const alternative blocks by
setting .option norvc after .option arch. This issue starts appearing on
gcc 15, which adds zca to the march.
Palmer Dabbelt [Wed, 26 Mar 2025 22:55:45 +0000 (15:55 -0700)]
Merge patch series "riscv: Relocatable NOMMU kernels"
Samuel Holland <samuel.holland@sifive.com> says:
Currently, RISC-V NOMMU kernels are linked at CONFIG_PAGE_OFFSET, and
since they are not relocatable, must be loaded at this address as well.
CONFIG_PAGE_OFFSET is not a user-visible Kconfig option, so its value is
not obvious, and users must patch the kernel source if they want to load
it at a different address.
Make NOMMU kernels more portable by making them relocatable by default.
This allows a single kernel binary to work when loaded at any address.
* b4-shazam-merge:
riscv: Remove CONFIG_PAGE_OFFSET
riscv: Support CONFIG_RELOCATABLE on riscv32
asm-generic: Always define Elf_Rel and Elf_Rela
riscv: Support CONFIG_RELOCATABLE on NOMMU
riscv: Allow NOMMU kernels to access all of RAM
riscv: Remove duplicate CONFIG_PAGE_OFFSET definition
Samuel Holland [Sat, 26 Oct 2024 17:13:58 +0000 (10:13 -0700)]
riscv: Remove CONFIG_PAGE_OFFSET
The current definition of CONFIG_PAGE_OFFSET is problematic for a couple
of reasons:
1) The value is misleading for normal 64-bit kernels, where it is
overridden at runtime if Sv48 or Sv39 is chosen. This is especially
the case for XIP kernels, which always use Sv39.
2) The option is not user-visible, but for NOMMU kernels it must be a
valid RAM address, and for !RELOCATABLE it must additionally be the
exact address where the kernel is loaded.
Fix both of these by removing the option.
1) For MMU kernels, drop the indirection through Kconfig. Additionally,
for XIP, drop the indirection through kernel_map.
2) For NOMMU kernels, use the user-visible physical RAM base if
provided. Otherwise, force the kernel to be relocatable.
Samuel Holland [Sat, 26 Oct 2024 17:13:57 +0000 (10:13 -0700)]
riscv: Support CONFIG_RELOCATABLE on riscv32
When adjusted to use the correctly-sized ELF types, relocate_kernel()
works on riscv32 as well. The caveat about crossing an intermediate page
table boundary does not apply to riscv32, since for Sv32 the early
kernel mapping uses only PGD entries. Since KASLR is not yet supported
on riscv32, this option is mostly useful for NOMMU.
Samuel Holland [Sat, 26 Oct 2024 17:13:55 +0000 (10:13 -0700)]
riscv: Support CONFIG_RELOCATABLE on NOMMU
Move relocate_kernel() out of the CONFIG_MMU block so it can be called
from the NOMMU version of setup_vm(). Set some offsets in kernel_map so
relocate_kernel() does not need to be modified. Relocatable NOMMU
kernels can be loaded to any physical memory address; they no longer
depend on CONFIG_PAGE_OFFSET.
Samuel Holland [Sat, 26 Oct 2024 17:13:54 +0000 (10:13 -0700)]
riscv: Allow NOMMU kernels to access all of RAM
NOMMU kernels currently cannot access memory below the kernel link
address. Remove this restriction by setting PAGE_OFFSET to the actual
start of RAM, as determined from the devicetree. The kernel link address
must be a constant, so keep using CONFIG_PAGE_OFFSET for that purpose.
Palmer Dabbelt [Wed, 26 Mar 2025 22:45:07 +0000 (15:45 -0700)]
RISC-V: errata: Use medany for relocatable builds
We're trying to mix non-PIC/PIE objects into the otherwise-PIE
relocatable kernels, to avoid GOT/PLT references during early boot
alternative resolution (which happens before the GOT/PLT are set up).
riscv64-unknown-linux-gnu-ld: arch/riscv/errata/sifive/errata.o: relocation R_RISCV_HI20 against `tlb_flush_all_threshold' can not be used when making a shared object; recompile with -fPIC
riscv64-unknown-linux-gnu-ld: arch/riscv/errata/thead/errata.o: relocation R_RISCV_HI20 against `riscv_cbom_block_size' can not be used when making a shared object; recompile with -fPIC
Palmer Dabbelt [Wed, 26 Mar 2025 22:54:12 +0000 (15:54 -0700)]
Merge tag 'riscv-mw1-6.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/alexghiti/linux into for-next
riscv patches for 6.15-rc1
* A bunch of fixes:
- We were missing a secondary mmu notifier call when flushing the tlb which is required for IOMMU
- Fix ftrace panics by saving the registers as expected by ftrace
- Fix a couple of stimecmp usage related to cpu hotplug
- Fix a bunch of issues in the misaligned probing handling
* Perf improvements:
- Introduce support for runtime constant improving perf of d_hash()
- Add support for huge pfnmaps to improve tlb utilization
- Use Zawrs to improve smp_cond_load8/16() used by the queued spinlocks
* Hwprobe additions:
- Add support for Zicntr and Zihpm
- Add support for Zaamo and Zalrsc
- Add support for bfloat16 extensiosn
- Add support for Zicbom (only enabling clean and flush, not inval for security reasons)
* Misc:
- Add a kernel parameter to bypass the misaligned speed probing since we can't rely on Zicclsm
* tag 'riscv-mw1-6.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/alexghiti/linux: (1585 commits)
riscv: Add runtime constant support
riscv: Move nop definition to insn-def.h
Documentation/kernel-parameters: Add riscv unaligned speed parameters
riscv: Add parameter for skipping access speed tests
riscv: Fix set up of vector cpu hotplug callback
riscv: Fix set up of cpu hotplug callbacks
riscv: Change check_unaligned_access_speed_all_cpus to void
riscv: Fix check_unaligned_access_all_cpus
riscv: Fix riscv_online_cpu_vec
riscv: Annotate unaligned access init functions
KVM: riscv: selftests: Add Zaamo/Zalrsc extensions to get-reg-list test
RISC-V: KVM: Allow Zaamo/Zalrsc extensions for Guest/VM
riscv: hwprobe: export Zaamo and Zalrsc extensions
riscv: add parsing for Zaamo and Zalrsc extensions
dt-bindings: riscv: add Zaamo and Zalrsc ISA extension description
riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler
riscv: fgraph: Select HAVE_FUNCTION_GRAPH_TRACER depends on HAVE_DYNAMIC_FTRACE_WITH_ARGS
riscv: Fix missing __free_pages() in check_vector_unaligned_access()
riscv: Fix the __riscv_copy_vec_words_unaligned implementation
riscv: mm: Don't use %pK through printk
...
The Unpriv spec states:
| The Zvknhb and Zvbc Vector Crypto Extensions --and accordingly the
| composite extensions Zvkn, Zvknc, Zvkng, and Zvksc-- require a Zve64x
| base, or application ("V") base Vector Extension. All of the other
| Vector Crypto Extensions can be built on any embedded (Zve*) or
| application ("V") base Vector Extension.
Section 33.18.2. Zve*: Vector Extensions for Embedded Processors
in [1] says:
| The Zve32f and Zve64x extensions depend on the Zve32x extension. The Zve64f extension depends
| on the Zve32f and Zve64x extensions. The Zve64d extension depends on the Zve64f extension
| The Zve32x extension depends on the Zicsr extension. The Zve32f and Zve64f extensions depend
| upon the F extension
| The Zve64d extension depends upon the D extension
Apply these rules to the bindings to help prevent invalid combinations.
Conor Dooley [Wed, 12 Mar 2025 13:11:47 +0000 (13:11 +0000)]
dt-bindings: riscv: d requires f
Per the specifications, the d extension for double-precision floating
point operations depends on the f extension for single-precision floating
point. Add that requirement to the bindings. This differs from the
Linux implementation, where single-precious only is not supported.
Conor Dooley [Wed, 12 Mar 2025 13:11:46 +0000 (13:11 +0000)]
RISC-V: add f & d extension validation checks
Using Clement's new validation callbacks, support checking that
dependencies have been satisfied for the floating point extensions.
The check for "d" might be slightly confusingly shorter than that of "f",
despite "d" depending on "f". This is because the requirement that a
hart supporting double precision must also support single precision,
should be validated by dt-bindings etc, not the kernel but lack of
support for single precision only is a limitation of the kernel.
Using Clement's new validation callbacks, support checking that
dependencies have been satisfied for the vector crpyto extensions.
Currently riscv_isa_extension_available(<vector crypto>) will return
true on systems that support the extensions but vector itself has been
disabled by the kernel, adding validation callbacks will prevent such a
scenario from occuring and make the behaviour of the extension detection
functions more consistent with user expectations - it's not expected to
have to check for vector AND the specific crypto extension.
The Unpriv spec states:
| The Zvknhb and Zvbc Vector Crypto Extensions --and accordingly the
| composite extensions Zvkn, Zvknc, Zvkng, and Zvksc-- require a Zve64x
| base, or application ("V") base Vector Extension. All of the other
| Vector Crypto Extensions can be built on any embedded (Zve*) or
| application ("V") base Vector Extension.
While this could be used as the basis for checking that the correct base
for individual crypto extensions, but that's not really the kernel's job
in my opinion and it is sufficient to leave that sort of precision to
the dt-bindings. The kernel only needs to make sure that vector, in some
form, is available.
Conor Dooley [Wed, 12 Mar 2025 13:11:44 +0000 (13:11 +0000)]
RISC-V: add vector extension validation checks
Using Clement's new validation callbacks, support checking that
dependencies have been satisfied for the vector extensions. From the
kernel's perfective, it's not required to differentiate between the
conditions for all the various vector subsets - it's the firmware's job
to not report impossible combinations. Instead, the kernel only has to
check that the correct config options are enabled and to enforce its
requirement of the d extension being present for FPU support.
Since vector will now be disabled proactively, there's no need to clear
the bit in elf_hwcap in riscv_fill_hwcap() any longer.
Alexandre Ghiti [Thu, 20 Mar 2025 07:31:07 +0000 (07:31 +0000)]
Merge patch series "riscv: Add runtime constant support"
Charlie Jenkins <charlie@rivosinc.com> says:
Ard brought this to my attention in this patch [1].
I benchmarked this patch on the Nezha D1 (which does not contain Zba or
Zbkb so it uses the default algorithm) by navigating through a large
directory structure. I created a 1000-deep directory structure and then
cd and ls through it. With this patch there was a 0.57% performance
improvement.
* patches from https://lore.kernel.org/r/20250319-runtime_const_riscv-v10-0-745b31a11d65@rivosinc.com:
riscv: Add runtime constant support
riscv: Move nop definition to insn-def.h
Charlie Jenkins [Wed, 19 Mar 2025 18:35:20 +0000 (11:35 -0700)]
riscv: Add runtime constant support
Implement the runtime constant infrastructure for riscv. Use this
infrastructure to generate constants to be used by the d_hash()
function.
This is the riscv variant of commit 94a2bc0f611c ("arm64: add 'runtime
constant' support") and commit e3c92e81711d ("runtime constants: add
x86 architecture support").
Charlie Jenkins [Wed, 19 Mar 2025 18:35:19 +0000 (11:35 -0700)]
riscv: Move nop definition to insn-def.h
We have duplicated the definition of the nop instruction in ftrace.h and
in jump_label.c. Move this definition into the generic file insn-def.h
so that they can share the definition with each other and with future
files.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20250319-runtime_const_riscv-v10-1-745b31a11d65@rivosinc.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Alexandre Ghiti [Wed, 19 Mar 2025 14:23:50 +0000 (14:23 +0000)]
Merge patch series "riscv: Unaligned access speed probing fixes and skipping"
Andrew Jones <ajones@ventanamicro.com> says:
The first six patches of this series are fixes and cleanups of the
unaligned access speed probing code. The next patch introduces a
kernel command line option that allows the probing to be skipped.
This command line option is a different approach than Jesse's [1].
[1] takes a cpu-list for a particular speed, supporting heterogeneous
platforms. With this approach, the kernel command line should only
be used for homogeneous platforms. [1] also only allowed 'fast' and
'slow' to be selected. This parameter also supports 'unsupported',
which could be useful for testing code paths gated on that. The final
patch adds the documentation.
* patches from https://lore.kernel.org/r/20250304120014.143628-10-ajones@ventanamicro.com:
Documentation/kernel-parameters: Add riscv unaligned speed parameters
riscv: Add parameter for skipping access speed tests
riscv: Fix set up of vector cpu hotplug callback
riscv: Fix set up of cpu hotplug callbacks
riscv: Change check_unaligned_access_speed_all_cpus to void
riscv: Fix check_unaligned_access_all_cpus
riscv: Fix riscv_online_cpu_vec
riscv: Annotate unaligned access init functions
Andrew Jones [Tue, 4 Mar 2025 12:00:22 +0000 (13:00 +0100)]
riscv: Add parameter for skipping access speed tests
Allow skipping scalar and vector unaligned access speed tests. This
is useful for testing alternative code paths and to skip the tests in
environments where they run too slowly. All CPUs must have the same
unaligned access speed.
The code movement is because we now need the scalar cpu hotplug
callback to always run, so we need to bring it and its supporting
functions out of CONFIG_RISCV_PROBE_UNALIGNED_ACCESS.
Andrew Jones [Tue, 4 Mar 2025 12:00:21 +0000 (13:00 +0100)]
riscv: Fix set up of vector cpu hotplug callback
Whether or not we have RISCV_PROBE_VECTOR_UNALIGNED_ACCESS we need to
set up a cpu hotplug callback to check if we have vector at all,
since, when we don't have vector, we need to set
vector_misaligned_access to unsupported rather than leave it the
default of unknown.
Andrew Jones [Tue, 4 Mar 2025 12:00:20 +0000 (13:00 +0100)]
riscv: Fix set up of cpu hotplug callbacks
CPU hotplug callbacks should be set up even if we detected all
current cpus emulate misaligned accesses, since we want to
ensure our expectations of all cpus emulating is maintained.
Andrew Jones [Tue, 4 Mar 2025 12:00:19 +0000 (13:00 +0100)]
riscv: Change check_unaligned_access_speed_all_cpus to void
The return value of check_unaligned_access_speed_all_cpus() is always
zero, so make the function void so we don't need to concern ourselves
with it. The change also allows us to tidy up
check_unaligned_access_all_cpus() a bit.
Andrew Jones [Tue, 4 Mar 2025 12:00:18 +0000 (13:00 +0100)]
riscv: Fix check_unaligned_access_all_cpus
check_vector_unaligned_access_emulated_all_cpus(), like its name
suggests, will return true when all cpus emulate unaligned vector
accesses. If the function returned false it may have been because
vector isn't supported at all (!has_vector()) or because at least
one cpu doesn't emulate unaligned vector accesses. Since false may
be returned for two cases, checking for it isn't sufficient when
attempting to determine if we should proceed with the vector speed
check. Move the !has_vector() functionality to
check_unaligned_access_all_cpus() in order for
check_vector_unaligned_access_emulated_all_cpus() to return false
for a single case.
Andrew Jones [Tue, 4 Mar 2025 12:00:17 +0000 (13:00 +0100)]
riscv: Fix riscv_online_cpu_vec
We shouldn't probe when we already know vector is unsupported and
we should probe when we see we don't yet know whether it's supported.
Furthermore, we should ensure we've set the access type to
unsupported when we don't have vector at all.
Alexandre Ghiti [Wed, 19 Mar 2025 11:50:03 +0000 (11:50 +0000)]
Merge patch series "riscv: add support for Zaamo and Zalrsc extensions"
Clément Léger <cleger@rivosinc.com> says:
Since commit e87412e621f1 ("integrate Zaamo and Zalrsc text (#1304)"),
the A extension has been described as a set of instructions provided by
Zaamo and Zalrsc. Add these two extensions.
This series is based on the Zc one [1].
Link: https://lore.kernel.org/linux-riscv/20240619113529.676940-1-cleger@rivosinc.com/
* patches from https://lore.kernel.org/lkml/20240619153913.867263-1-cleger@rivosinc.com/:
dt-bindings: riscv: add Zaamo and Zalrsc ISA extension description
riscv: add parsing for Zaamo and Zalrsc extensions
riscv: hwprobe: export Zaamo and Zalrsc extensions
RISC-V: KVM: Allow Zaamo/Zalrsc extensions for Guest/VM
KVM: riscv: selftests: Add Zaamo/Zalrsc extensions to get-reg-list
test
Clément Léger [Wed, 19 Jun 2024 15:39:09 +0000 (17:39 +0200)]
riscv: add parsing for Zaamo and Zalrsc extensions
These 2 new extensions are actually a subset of the A extension which
provides atomic memory operations and load-reserved/store-conditional
instructions.
Pu Lehui [Mon, 17 Mar 2025 03:12:14 +0000 (03:12 +0000)]
riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler
Naresh Kamboju reported a "Bad frame pointer" kernel warning while
running LTP trace ftrace_stress_test.sh in riscv. We can reproduce the
same issue with the following command:
The reason is that the stack layout for constructing argument for the
ftrace_return_to_handler in the return_to_handler does not match the
__arch_ftrace_regs structure of riscv, leading to unexpected results.
Fixes: a3ed4157b7d8 ("fgraph: Replace fgraph_ret_regs with ftrace_regs") Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Closes: https://lore.kernel.org/all/CA+G9fYvp_oAxeDFj88Tk2rfEZ7jtYKAKSwfYS66=57Db9TBdyA@mail.gmail.com Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Link: https://lore.kernel.org/r/20250317031214.4138436-2-pulehui@huaweicloud.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Pu Lehui [Mon, 17 Mar 2025 03:12:13 +0000 (03:12 +0000)]
riscv: fgraph: Select HAVE_FUNCTION_GRAPH_TRACER depends on HAVE_DYNAMIC_FTRACE_WITH_ARGS
Currently, fgraph on riscv relies on the infrastructure of
DYNAMIC_FTRACE_WITH_ARGS. However, DYNAMIC_FTRACE_WITH_ARGS may be
turned off on riscv, which will cause the enabled fgraph to be abnormal.
Therefore, let's select HAVE_FUNCTION_GRAPH_TRACER depends on
HAVE_DYNAMIC_FTRACE_WITH_ARGS.
Fixes: a3ed4157b7d8 ("fgraph: Replace fgraph_ret_regs with ftrace_regs") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202503160820.dvqMpH0g-lkp@intel.com/ Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20250317031214.4138436-1-pulehui@huaweicloud.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Juhan Jin [Thu, 6 Feb 2025 19:28:36 +0000 (13:28 -0600)]
riscv: ftrace: Add parentheses in macro definitions of make_call_t0 and make_call_ra
This patch adds parentheses to parameters caller and callee of macros
make_call_t0 and make_call_ra. Every existing invocation of these two
macros uses a single variable for each argument, so the absence of the
parentheses seems okay. However, future invocations might use more
complex expressions as arguments. For example, a future invocation might
look like this: make_call_t0(a - b, c, call). Without parentheses in the
macro definition, the macro invocation expands to:
...
unsigned int offset = (unsigned long) c - (unsigned long) a - b;
...
which is clearly wrong.
The use of parentheses ensures arguments are correctly evaluated and
potentially saves future users of make_call_t0 and make_call_ra debugging
trouble.
Fixes: 6724a76cff85 ("riscv: ftrace: Reduce the detour code size to half") Signed-off-by: Juhan Jin <juhan.jin@foxmail.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/tencent_AE90AA59903A628E87E9F80E563DA5BA5508@qq.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Charlie Jenkins [Tue, 25 Feb 2025 02:42:21 +0000 (18:42 -0800)]
riscv: tracing: Fix __write_overflow_field in ftrace_partial_regs()
The size of ®s->a0 is unknown, causing the error:
../include/linux/fortify-string.h:571:25: warning: call to
'__write_overflow_field' declared with attribute warning: detected write
beyond size of field (1st parameter); maybe use struct_group()?
[-Wattribute-warning]
Fix this by wrapping the required registers in pt_regs with
struct_group() and reference the group when doing the offending
memcpy().
Geert Uytterhoeven [Wed, 5 Feb 2025 14:09:03 +0000 (15:09 +0100)]
riscv: Remove duplicate CLINT_TIMER selections
Since commit f862bbf4cdca696e ("riscv: Allow NOMMU kernels to run in
S-mode") in v6.10, CLINT_TIMER is selected by the main RISCV symbol when
RISCV_M_MODE is enabled.
Geert Uytterhoeven [Wed, 5 Feb 2025 14:07:17 +0000 (15:07 +0100)]
riscv: defconfig: Disable Renesas SoC support
Follow-up to commit e36ddf3226864e09 ("riscv: defconfig: Disable RZ/Five
peripheral support") in v6.12-rc1:
- Disable ARCH_RENESAS, too, as currently RZ/Five is the sole Renesas
RISC-V SoC,
- Drop no longer needed explicit disable of USB_XHCI_RCAR, which
depends on ARCH_RENESAS.
Alexandre Ghiti [Tue, 18 Mar 2025 12:59:08 +0000 (12:59 +0000)]
Merge patch series "Support SSTC while PM operations"
Nick Hu <nick.hu@sifive.com> says:
When the cpu is going to be hotplug, stop the stimecmp to prevent pending
interrupt.
When the cpu is going to be suspended, save the stimecmp before entering
the suspend state and restore it in the resume path.
* patches from https://lore.kernel.org/r/20250219114135.27764-1-nick.hu@sifive.com:
clocksource/drivers/timer-riscv: Stop stimecmp when cpu hotplug
riscv: Add stimecmp save and restore
Chin Yik Ming [Wed, 29 Jan 2025 20:38:43 +0000 (04:38 +0800)]
riscv: Simplify base extension checks and direct boolean return
Reduce three lines checking to single line using a ternary conditional
expression for getting the base extension word. In addition, the
test_bit macro function already return a boolean which matches the
return type of the caller, so directly return the result of the test_bit
macro function.
Yunhui Cui [Wed, 26 Feb 2025 06:32:06 +0000 (14:32 +0800)]
RISC-V: selftests: Add TEST_ZICBOM into CBO tests
Add test for Zicbom and its block size into CBO tests, when
Zicbom is present, test that cbo.clean/flush may be issued and works.
As the software can't verify the clean/flush functions, we just judged
that cbo.clean/flush isn't executed illegally.
Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Samuel Holland <samuel.holland@sifive.com> Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Link: https://lore.kernel.org/r/20250226063206.71216-4-cuiyunhui@bytedance.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Yunhui Cui [Wed, 26 Feb 2025 06:32:05 +0000 (14:32 +0800)]
RISC-V: hwprobe: Expose Zicbom extension and its block size
Expose Zicbom through hwprobe and also provide a key to extract its
respective block size.
[ alex: Fix merge conflicts and hwprobe numbering ]
Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Samuel Holland <samuel.holland@sifive.com> Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Link: https://lore.kernel.org/r/20250226063206.71216-3-cuiyunhui@bytedance.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Alexandre Ghiti [Tue, 18 Mar 2025 11:52:54 +0000 (11:52 +0000)]
Merge patch series "riscv: Add bfloat16 instruction support"
Inochi Amaoto <inochiama@gmail.com> says:
Add description for the BFloat16 precision Floating-Point ISA extension,
(Zfbfmin, Zvfbfmin, Zvfbfwma). which was ratified in commit 4dc23d62
("Added Chapter title to BF16") of the riscv-isa-manual.
* patches from https://lore.kernel.org/r/20250213003849.147358-1-inochiama@gmail.com:
riscv: hwprobe: export bfloat16 ISA extension
riscv: add ISA extension parsing for bfloat16 ISA extension
dt-bindings: riscv: add bfloat16 ISA extension description
Inochi Amaoto [Thu, 13 Feb 2025 00:38:45 +0000 (08:38 +0800)]
dt-bindings: riscv: add bfloat16 ISA extension description
Add description for the BFloat16 precision Floating-Point ISA extension,
(Zfbfmin, Zvfbfmin, Zvfbfwma). which was ratified in commit 4dc23d62
("Added Chapter title to BF16") of the riscv-isa-manual.
Guo Ren [Tue, 17 Dec 2024 01:39:10 +0000 (20:39 -0500)]
riscv: Implement smp_cond_load8/16() with Zawrs
RISC-V code uses the queued spinlock implementation, which calls
the macros smp_cond_load_acquire for one byte. So, complement the
implementation of byte and halfword versions.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Signed-off-by: Guo Ren <guoren@kernel.org> Cc: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20241217013910.1039923-1-guoren@kernel.org Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Andrew Bresticker [Wed, 8 Jan 2025 13:57:00 +0000 (05:57 -0800)]
riscv: Support huge pfnmaps
Use RSW0 as the special bit for pmds and puds, just like for ptes.
Also define the {pte,pmd,pud}_pgprot helpers which were previously
missing and are needed for the follow_pfnmap APIs.
Alexandre Ghiti [Tue, 18 Mar 2025 08:53:10 +0000 (08:53 +0000)]
Merge patch series "RISC-V: clarify what some RISCV_ISA* config options do & redo Zbb toolchain dependency"
Conor Dooley <conor@kernel.org> says:
Since one depends on the other, albeit trivially, here's a v4 of the Zbb
toolchain dep removal alongside the rewording of Kconfig options I'd
sent out before the merge window. I think I like this implementation
better than v1, but I couldn't think of a good name for a "public"
version of __ALTERNATIVE(), so I used it here directly.
Unfortunately "ALTERNATIVE_2_CFG" already exists and I couldn't think of
a good way to name an alternative macro that allows for several config
options that didn't make the distinction sufficiently clear.. Yell
if you have better suggestions than I did.
I am a wee bit "worried" that this makes the Kconfig option confusing as
it isn't immediately obvious if someone is or is not going to get the
toolchain based optimisations.
Cheers,
Conor.
* patches from https://lore.kernel.org/r/20241024-aspire-rectify-9982da6943e5@spud:
RISC-V: separate Zbb optimisations requiring and not requiring toolchain support
RISC-V: clarify what some RISCV_ISA* config options do
Conor Dooley [Thu, 24 Oct 2024 10:19:41 +0000 (11:19 +0100)]
RISC-V: separate Zbb optimisations requiring and not requiring toolchain support
It seems a bit ridiculous to require toolchain support for BPF to
assemble Zbb instructions, so move the dependency on toolchain support
for Zbb optimisations out of the Kconfig option and to the callsites.
Zbb support has always depended on alternatives, so while adjusting the
config options guarding optimisations, remove any checks for
whether or not alternatives are enabled.
Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Samuel Holland <samuel.holland@sifive.com> Link: https://lore.kernel.org/r/20241024-chump-freebase-d26b6d81af33@spud Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Conor Dooley [Thu, 24 Oct 2024 10:19:40 +0000 (11:19 +0100)]
RISC-V: clarify what some RISCV_ISA* config options do
During some discussion on IRC yesterday and on Pu's bpf patch [1]
I noticed that these RISCV_ISA* Kconfig options are not really clear
about their implications. Many of these options have no impact on what
userspace is allowed to do, for example an application can use Zbb
regardless of whether or not the kernel does. Change the help text to
try and clarify whether or not an option affects just the kernel, or
also userspace. None of these options actually control whether or not an
extension is detected dynamically as that's done regardless of Kconfig
options, so drop any text that implies the option is required for
dynamic detection, rewording them as "do x when y is detected".
Linus Torvalds [Sun, 16 Mar 2025 19:09:44 +0000 (09:09 -1000)]
Merge tag 'i2c-for-6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
- omap: fix irq ACKS to avoid irq storming and system hang
- ali1535, ali15x3, sis630: fix error path at probe exit
* tag 'i2c-for-6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: sis630: Fix an error handling path in sis630_probe()
i2c: ali15x3: Fix an error handling path in ali15x3_probe()
i2c: ali1535: Fix an error handling path in ali1535_probe()
i2c: omap: fix IRQ storms
Linus Torvalds [Sun, 16 Mar 2025 19:05:00 +0000 (09:05 -1000)]
Merge tag 'trace-v6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fix from Steven Rostedt:
"Fix ref count of trace_array in error path of histogram file open
Tracing instances have a ref count to keep them around while files
within their directories are open. This prevents them from being
deleted while they are used.
The histogram code had some files that needed to take the ref count
and that was added, but the error paths did not decrement the ref
counts. This caused the instances from ever being removed if a
histogram file failed to open due to some error"
* tag 'trace-v6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
tracing: Correct the refcount if the hist/hist_debug file fails to open
Linus Torvalds [Sun, 16 Mar 2025 06:39:55 +0000 (20:39 -1000)]
Merge tag 'usb-6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB and Thunderbolt driver fixes and new
usb-serial device ids. Included in here are:
- new usb-serial device ids
- typec driver bugfix
- thunderbolt driver resume bugfix
All of these have been in linux-next with no reported issues"
* tag 'usb-6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: typec: tcpm: fix state transition for SNK_WAIT_CAPABILITIES state in run_state_machine()
USB: serial: ftdi_sio: add support for Altera USB Blaster 3
thunderbolt: Prevent use-after-free in resume from hibernate
USB: serial: option: fix Telit Cinterion FE990A name
USB: serial: option: add Telit Cinterion FE990B compositions
USB: serial: option: match on interface class for Telit FN990B
Linus Torvalds [Sun, 16 Mar 2025 01:46:29 +0000 (15:46 -1000)]
Merge tag 'input-for-v6.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input updates from Dmitry Torokhov:
- several new device IDs added to xpad game controller driver
- support for imagis IST3038H variant of chip added to imagis touch
controller driver
- a fix for GPIO allocation for ads7846 touch controller driver
- a fix for iqs7222 driver to properly support status register
- a fix for goodix-berlin touch controller driver to use the right name
for the regulator
- more i8042 quirks to better handle several old Clevo devices.
* tag 'input-for-v6.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
MAINTAINERS: Remove myself from the goodix touchscreen maintainers
Input: iqs7222 - preserve system status register
Input: i8042 - swap old quirk combination with new quirk for more devices
Input: i8042 - swap old quirk combination with new quirk for several devices
Input: i8042 - add required quirks for missing old boardnames
Input: i8042 - swap old quirk combination with new quirk for NHxxRZQ
Input: xpad - rename QH controller to Legion Go S
Input: xpad - add support for TECNO Pocket Go
Input: xpad - add support for ZOTAC Gaming Zone
Input: goodix-berlin - fix vddio regulator references
Input: goodix-berlin - fix comment referencing wrong regulator
Input: imagis - add support for imagis IST3038H
dt-bindings: input/touchscreen: imagis: add compatible for ist3038h
Input: xpad - add multiple supported devices
Input: xpad - add 8BitDo SN30 Pro, Hyperkin X91 and Gamesir G7 SE controllers
Input: ads7846 - fix gpiod allocation
Input: wdt87xx_i2c - fix compiler warning
Linus Torvalds [Sat, 15 Mar 2025 18:32:16 +0000 (08:32 -1000)]
Merge tag 'fsnotify_for_v6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
Pull fsnotify reverts from Jan Kara:
"Syzbot has found out that fsnotify HSM events generated on page fault
can be generated while we already hold freeze protection for the
filesystem (when you do buffered write from a buffer which is mmapped
file on the same filesystem) which violates expectations for HSM
events and could lead to deadlocks of HSM clients with filesystem
freezing.
Since it's quite late in the cycle we've decided to revert changes
implementing HSM events on page fault for now and instead just
generate one event for the whole range on mmap(2) so that HSM client
can fetch the data at that moment"
* tag 'fsnotify_for_v6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
Revert "fanotify: disable readahead if we have pre-content watches"
Revert "mm: don't allow huge faults for files with pre content watches"
Revert "fsnotify: generate pre-content permission event on page fault"
Revert "xfs: add pre-content fsnotify hook for DAX faults"
Revert "ext4: add pre-content fsnotify hook for DAX faults"
fsnotify: add pre-content hooks on mmap()
Linus Torvalds [Sat, 15 Mar 2025 04:43:37 +0000 (18:43 -1000)]
Merge tag 'v6.14-rc6-smb3-server-fixes' of git://git.samba.org/ksmbd
Pull smb server fixes from Steve French:
- Two fixes for oplock break/lease races
* tag 'v6.14-rc6-smb3-server-fixes' of git://git.samba.org/ksmbd:
ksmbd: prevent connection release during oplock break notification
ksmbd: fix use-after-free in ksmbd_free_work_struct
Kent Overstreet [Fri, 14 Mar 2025 22:20:20 +0000 (18:20 -0400)]
bcachefs: fix build on 32 bit in get_random_u64_below()
bare 64 bit divides not allowed, whoops
arm-linux-gnueabi-ld: drivers/char/random.o: in function `__get_random_u64_below':
drivers/char/random.c:602:(.text+0xc70): undefined reference to `__aeabi_uldivmod'
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Linus Torvalds [Fri, 14 Mar 2025 22:14:32 +0000 (12:14 -1000)]
Merge tag 'bcachefs-2025-03-14' of git://evilpiepirate.org/bcachefs
Pull bcachefs hotfix from Kent Overstreet:
"This one is high priority: a user hit an assertion in the upgrade to
6.14, and we don't have a reproducer, so this changes the assertion to
an emergency read-only with more info so we can debug it"
* tag 'bcachefs-2025-03-14' of git://evilpiepirate.org/bcachefs:
bcachefs: Change btree wb assert to runtime error
Linus Torvalds [Fri, 14 Mar 2025 21:31:57 +0000 (11:31 -1000)]
Merge tag 'for-6.14/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fix from Mikulas Patocka:
- dm-flakey: fix memory corruption in optional corrupt_bio_byte feature
* tag 'for-6.14/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm-flakey: Fix memory corruption in optional corrupt_bio_byte feature
Linus Torvalds [Fri, 14 Mar 2025 21:22:05 +0000 (11:22 -1000)]
Merge tag 'block-6.14-20250313' of git://git.kernel.dk/linux
Pull block fixes from Jens Axboe:
- NVMe pull request via Keith:
- Concurrent pci error and hotplug handling fix (Keith)
- Endpoint function fixes (Damien)
- Fix for a regression introduced in this cycle with error checking for
batched request completions (Shin'ichiro)
* tag 'block-6.14-20250313' of git://git.kernel.dk/linux:
block: change blk_mq_add_to_batch() third argument type to bool
nvme: move error logging from nvme_end_req() to __nvme_end_req()
nvmet: pci-epf: Do not add an IRQ vector if not needed
nvmet: pci-epf: Set NVMET_PCI_EPF_Q_LIVE when a queue is fully created
nvme-pci: fix stuck reset on concurrent DPC and HP
Linus Torvalds [Fri, 14 Mar 2025 20:57:28 +0000 (10:57 -1000)]
Merge tag 'platform-drivers-x86-v6.14-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Ilpo Järvinen:
"Fixes and new HW support.
The diff is a bit larger than I'd prefer at this point due to
unwinding the amd/pmf driver's error handling properly instead of
calling a deinit function that was a can full of worms.
Summary:
- amd/pmf:
- Fix error handling in amd_pmf_init_smart_pc()
- Fix missing hidden options for Smart PC
- surface: aggregator_registry: Add Support for Surface Pro 11"
* tag 'platform-drivers-x86-v6.14-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
MAINTAINERS: Update Ike Panhc's email address
platform/x86/amd: pmf: Fix missing hidden options for Smart PC
platform/surface: aggregator_registry: Add Support for Surface Pro 11
platform/x86/amd/pmf: fix cleanup in amd_pmf_init_smart_pc()
Linus Torvalds [Fri, 14 Mar 2025 20:39:41 +0000 (10:39 -1000)]
Merge tag 'gpio-fixes-for-v6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
"The first fix is a backport from my v6.15-rc1 queue that turned out to
be needed in v6.14 as well but as the former diverged from my fixes
branch I had to adjust the patch a bit.
The second one fixes a regression observed in user-space where closing
a file descriptor associated with a GPIO device results in a ~10ms
delay due to the atomic notifier calling rcu_synchronize() when
unregistering.
Summary:
- don't check the return value of gpio_chip::get_direction() when
registering a GPIO chip
- use raw notifier for line state events"
* tag 'gpio-fixes-for-v6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: cdev: use raw notifier for line state events
gpiolib: don't check the retval of get_direction() when registering a chip
Linus Torvalds [Fri, 14 Mar 2025 20:35:39 +0000 (10:35 -1000)]
Merge tag 'sound-6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of last-minute fixes.
Most of them are for ASoC, and the only one core fix is for reverting
the previous change, while the rest are all device-specific quirks and
fixes, which should be relatively safe to apply"
* tag 'sound-6.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: cs42l43: convert to SYSTEM_SLEEP_PM_OPS
ALSA: hda/realtek: Add mute LED quirk for HP Pavilion x360 14-dy1xxx
ASoC: codecs: wm0010: Fix error handling path in wm0010_spi_probe()
ASoC: rt722-sdca: add missing readable registers
ASoC: amd: yc: Support mic on another Lenovo ThinkPad E16 Gen 2 model
ASoC: cs42l43: Fix maximum ADC Volume
ASoC: ops: Consistently treat platform_max as control value
ASoC: rt1320: set wake_capable = 0 explicitly
ASoC: cs42l43: Add jack delay debounce after suspend
ASoC: tegra: Fix ADX S24_LE audio format
ASoC: codecs: wsa884x: report temps to hwmon in millidegree of Celsius
ASoC: Intel: sof_sdw: Fix unlikely uninitialized variable use in create_sdw_dailinks()
Linus Torvalds [Fri, 14 Mar 2025 20:24:57 +0000 (10:24 -1000)]
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"The main one is a horrible macro fix for our TLB flushing code which
resulted in over-invalidation on the MMU notifier path.
Summary:
- Fix population of the vmemmap for regions of memory that are
smaller than a section (128 MiB)
- Fix range-based TLB over-invalidation when invoked via a MMU
notifier"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
Fix mmu notifiers for range-based invalidates
arm64: mm: Populate vmemmap at the page level if not section aligned
Linus Torvalds [Fri, 14 Mar 2025 20:07:16 +0000 (10:07 -1000)]
Merge tag 'x86-urgent-2025-03-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Ingo Molnar:
"Fix the bootup of SEV-SNP enabled guests under VMware hypervisors"
* tag 'x86-urgent-2025-03-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/vmware: Parse MP tables for SEV-SNP enabled guests under VMware hypervisors
Linus Torvalds [Fri, 14 Mar 2025 19:56:46 +0000 (09:56 -1000)]
Merge tag 'sched-urgent-2025-03-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fix from Ingo Molnar:
"Fix a sleeping-while-atomic bug caused by a recent optimization
utilizing static keys that didn't consider that the
static_key_disable() call could be triggered in atomic context.
Revert the optimization"
* tag 'sched-urgent-2025-03-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/clock: Don't define sched_clock_irqtime as static key
Linus Torvalds [Fri, 14 Mar 2025 19:41:36 +0000 (09:41 -1000)]
Merge tag 'locking-urgent-2025-03-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull misc locking fixes from Ingo Molnar:
- Restrict the Rust runtime from unintended access to dynamically
allocated LockClassKeys
- KernelDoc annotation fix
- Fix a lock ordering bug in semaphore::up(), related to trying to
printk() and wake up the console within critical sections
* tag 'locking-urgent-2025-03-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking/semaphore: Use wake_q to wake up processes outside lock critical section
locking/rtmutex: Use the 'struct' keyword in kernel-doc comment
rust: lockdep: Remove support for dynamically allocated LockClassKeys
Linus Torvalds [Fri, 14 Mar 2025 19:12:28 +0000 (09:12 -1000)]
Merge tag 'core-urgent-2025-03-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull core fix from Ingo Molnar:
"Fix a Sparse false positive warning triggered by no_free_ptr()"
* tag 'core-urgent-2025-03-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
<linux/cleanup.h>: Allow the passing of both iomem and non-iomem pointers to no_free_ptr()