| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The common coldfire code uses the old GPIO number based interfaces for
at least the QSPI chipselect lines. Select the required Kconfig symbol
to keep it building when that becomes optional.
Apparently there are no devices attached to a QSPI controller in any of
the coldfire boards, so this is not actually used in upstream kernels.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
|
|
Sysam name has changed to Kernelspace, updating each reference.
Signed-off-by: Angelo Dureghello <angelo@kernel-space.org>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
|
|
Various updates, mainly to reduce kernel size.
Signed-off-by: Angelo Dureghello <angelo@kernel-space.org>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
- Add more AMD Zen6 models (Pratik Vishwakarma)
- Avoid confusing bootup message by the Intel resctl enumeration
code when running on certain AMD systems (Tony Luck)
* tag 'x86-urgent-2026-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/resctrl: Only check Intel systems for SNC
x86/CPU/AMD: Add more Zen6 models
|
|
Adding struct bpf_tramp_node to decouple the link out of the trampoline
attachment info.
At the moment the object for attaching bpf program to the trampoline is
'struct bpf_tramp_link':
struct bpf_tramp_link {
struct bpf_link link;
struct hlist_node tramp_hlist;
u64 cookie;
}
The link holds the bpf_prog pointer and forces one link - one program
binding logic. In following changes we want to attach program to multiple
trampolines but we want to keep just one bpf_link object.
Splitting struct bpf_tramp_link into:
struct bpf_tramp_link {
struct bpf_link link;
struct bpf_tramp_node node;
};
struct bpf_tramp_node {
struct bpf_link *link;
struct hlist_node tramp_hlist;
u64 cookie;
};
The 'struct bpf_tramp_link' defines standard single trampoline link
and 'struct bpf_tramp_node' is the attachment trampoline object with
pointer to the bpf_link object.
This will allow us to define link for multiple trampolines, like:
struct bpf_tracing_multi_link {
struct bpf_link link;
...
int nodes_cnt;
struct bpf_tracing_multi_node nodes[] __counted_by(nodes_cnt);
};
Cc: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20260606123955.345967-9-jolsa@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
For the 64K granule size, FEAT_LPA determines whether a level 1 mapping
is allowed. Using the result of has_52bit_pa() is too restrictive, as it
also checks the selected output addressi size in TCR.(I)PS. Fix it by
only checking FEAT_LPA.
Fixes: 5da3a3b27a01 ("KVM: arm64: Expand valid block mappings to FEAT_LPA/LPA2 support")
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
Link: https://patch.msgid.link/20260605185255.2431996-1-weilin.chang@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
If kvm_call_hyp_nvhe() fails with an SMCCC error code, we WARN().
However, the returned value isn't initialized and the caller might get
garbage or 0 which is likely to be interpreted as success.
Set a default -EOPNOTSUPP error value, ensuring all callers get the
message when hypercalls fail.
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Acked-by: Will Deacon <will@kernel.org>
Reviewed-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260603110312.2909844-1-vdonnefort@google.com
[maz: changed error value to -EOPNOTSUPP as suggested by Will,
tidied up change log]
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
kvm_share_hyp() shares a range one page at a time. If share_pfn_hyp()
fails partway through, the pages already shared by this call are left
shared, while the caller treats the whole range as failed and never
unshares them.
Unshare those pages before returning the error. If an unshare itself
fails the page is leaked: it stays shared with the hypervisor and is
no longer reusable for pKVM, but no isolation guarantee is broken, so
WARN and continue. Not expected in practice.
Fixes: a83e2191b7f1 ("KVM: arm64: pkvm: Refcount the pages shared with EL2")
Suggested-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Link: https://patch.msgid.link/20260529121755.2923500-4-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
unshare_pfn_hyp() erases the tracking node from hyp_shared_pfns
and frees it before invoking __pkvm_host_unshare_hyp. If the
hypercall fails (e.g. EL2 refcount still held, or page-state
mismatch), the host loses its record while EL2 still holds the
share, breaking later share/unshare attempts on the same pfn.
Invoke the hypercall first; erase and free only on success.
Document at the kvm_unshare_hyp() call site that the WARN_ON() is
left non-fatal: a failed unshare leaks the page (it stays shared
with the hypervisor) but breaks no isolation guarantee.
Fixes: 52b28657ebd7 ("KVM: arm64: pkvm: Unshare guest structs during teardown")
Reported-by: Sashiko (local):gemini-3.1-pro
Suggested-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Link: https://patch.msgid.link/20260529121755.2923500-3-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
share_pfn_hyp() inserts a tracking node into hyp_shared_pfns and
then invokes __pkvm_host_share_hyp. If the hypercall rejects the
share (page-state mismatch at EL2), the node stays in the tree
with refcount 1: a phantom share that leaks the allocation and
that a later unshare will trust.
Erase the node and free it on hypercall failure.
Fixes: a83e2191b7f1 ("KVM: arm64: pkvm: Refcount the pages shared with EL2")
Reported-by: Sashiko (local):gemini-3.1-pro
Suggested-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Link: https://patch.msgid.link/20260529121755.2923500-2-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
With pKVM enabled, the host injects a virtual SError by setting
HCR_EL2.VSE on its vCPU copy, but flush_hyp_vcpu() only flows TWI/TWE
into the hyp vCPU that runs, so VSE never reaches it and a deferred
(masked) SError is never delivered. VSE is a host-owned injection
control, not a trap-configuration bit, so restricting the host's
trap-register values should not have dropped it.
Flow it on entry; sync_hyp_vcpu() already copies hcr_el2 back, so
delivery is reflected to the host. THis makes it consistent with
the existing forwarding of VSESR_EL2, which qualifies the Serror.
Fixes: b56680de9c648 ("KVM: arm64: Initialize trap register values in hyp in pKVM")
Reported-by: Sashiko (local):gemini-3.1-pro
Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Oliver Upton <oupton@kernel.org>
Link: https://patch.msgid.link/20260531154548.1505799-1-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
flush_hyp_vcpu() copies the host vGIC state into the hyp's private vCPU
on every run. The vGIC list register save and restore use used_lrs as
their loop bound and expect it to stay within the number of implemented
list registers. While this is generally the case, flush_hyp_vcpu()
copies vgic_v3 verbatim and does not enforce this, so a value provided
by the host is used at EL2 to index vgic_lr[] and access ICH_LR<n>_EL2
(host -> EL2).
Fix by clamping used_lrs to the number of implemented list registers
after the copy, as the trusted path already does in
vgic_flush_lr_state(). The number of implemented list registers is
constant after init, so it is replicated once from
kvm_vgic_global_state.nr_lr into hyp_gicv3_nr_lr rather than read on
every entry.
Cc: stable@vger.kernel.org
Fixes: be66e67f1750 ("KVM: arm64: Use the pKVM hyp vCPU structure in handle___kvm_vcpu_run()")
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260606175614.83273-3-imv4bel@gmail.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
flush_hyp_vcpu() copies the host vCPU context into the hyp's private
vCPU on every run. ctxt_to_vcpu() expects a guest context to have a
NULL __hyp_running_vcpu, which is only ever set on the host context, so
that it resolves the vCPU via container_of(). While this is generally
the case, flush_hyp_vcpu() copies the context verbatim and does not
enforce this, so a value provided by the host is dereferenced at EL2
(host -> EL2).
Fix by clearing __hyp_running_vcpu after the copy.
Cc: stable@vger.kernel.org
Fixes: be66e67f1750 ("KVM: arm64: Use the pKVM hyp vCPU structure in handle___kvm_vcpu_run()")
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260606175614.83273-2-imv4bel@gmail.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
On RISC-V, also select ARCH_KEEP_MEMBLOCK if kexec is selected, not
only if ACPI is selected. This is because kexec requires the memblock
areas to be kept after boot to initialize the secondary kernel. This
is needed for both Device Tree and ACPI platforms.
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Link: https://patch.msgid.link/20260519165546.123105-1-gaohan@iscas.ac.cn
[pjw@kernel.org: change to add the dependency on kexec, rather than making it unconditional;
rewrite the patch description accordingly]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
The dedicated vDSO for CFI-enabled userspace can also contain
alternative entries.
Patch those, too.
Fixes: ccad8c1336b6 ("arch/riscv: add dual vdso creation logic and select vdso based on hw")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-4-bcdf3d37f62e@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
The dedicated vDSO with CFI should also be patched in the same way.
To prepare for that move the currently hardcoded vDSO start symbol
into a parameter.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-3-bcdf3d37f62e@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
apply_vdso_alternatives()
IS_ENABLED() allows better compilation coverage while still optimizing
away all the dead code. Also it will make some upcoming changes easier.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-2-bcdf3d37f62e@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Make the declarations of vdso_start and its related symbols always
visible. With that their users don't have to use ifdeffery but can
use the better IS_ENABLED() compile-time checks.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-1-bcdf3d37f62e@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Use min() to replace the open-coded version and assign the result
directly to kbuf.bufsz. Drop the now-unused local size variable.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260602224725.1088385-3-thorsten.blum@linux.dev
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
init_irq_stacks() and init_irq_scs() may fail when arch_alloc_vmap_stack
or scs_alloc return NULL, call panic() in this case.
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Link: https://patch.msgid.link/20260404185522.21767-1-osama.abdelkader@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Same as kvm_riscv_gstage_wp_range, the possible valid pages should not
be skipped if !found_leaf. Different from wp case, which can
write-protect more than asked, unmap can't do that, no splitting is
added right now but a warning is logged instead.
Signed-off-by: Wu Fei <wu.fei9@sanechips.com.cn>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260604230317.30501-3-atwufei@163.com
Signed-off-by: Anup Patel <anup@brainfault.org>
|
|
The current gstage range walker unconditionally advances by 'page_size'
when a leaf PTE is not found, e.g. when the range to wp is
[0xfffff01fc000, 0xfffff023c000) and page_size is 2MB, if found_leaf of
0xfffff01fc000 returns false, it skip the whole range, but it's possible
to have valid entries in [0xfffff0200000, 0xfffff023c000).
Signed-off-by: Wu Fei <wu.fei9@sanechips.com.cn>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260604230317.30501-2-atwufei@163.com
Signed-off-by: Anup Patel <anup@brainfault.org>
|
|
Svvptc does not guarantee that it's safe to just return here. Since we
have already cleared our bit, if, theoretically, the bounded timeframe
for the accessed page to become valid still hasn't happened after sret,
we could fault again and actually crash.
Hopefully, these spurious faults should be rare enough that this is an
acceptable slowdown.
Cc: stable@vger.kernel.org
Fixes: 503638e0babf ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings")
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-5-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
The bitmap was defined with incorrect size. Fix it by using the proper
bitmap API in C code. The corresponding assembly code is still okay and
remains unchanged.
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-4-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Since this mechanism is now used for the kfence pool, which comes from
the linear mapping and not vmalloc, rename new_vmalloc into
new_valid_map_cpus to avoid misleading readers.
No functional change intended.
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-3-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
In kfence_protect_page(), which kfence_unprotect() calls, we cannot send
IPIs to other CPUs to ask them to flush TLB. This may lead to those CPUs
spuriously faulting on a recently allocated kfence object despite it
being valid, leading to false positive use-after-free reports.
Fix this by calling mark_new_valid_map() so that the page fault handling
code path notices the spurious fault and flushes TLB then retries the
access.
Update the comment in handle_exception to indicate that
new_valid_map_cpus_check also handles kfence_unprotect() spurious
faults.
Note that kfence_protect() has the same stale TLB entries problem, but
that leads to false negatives, which is fine with kfence.
Cc: stable@vger.kernel.org
Reported-by: Yanko Kaneti <yaneti@declera.com>
Fixes: b3431a8bb336 ("riscv: Fix IPIs usage in kfence_protect_page()")
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-2-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
In preparation of a future patch using the same mechanism for
non-vmalloc addresses, extract the mark_new_valid_map() helper from
flush_cache_vmap().
No functional change intended.
Cc: stable@vger.kernel.org
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-1-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
In the non-frame-pointer version of walk_stackframe, each value read
from the stack is treated as a potential return address and has 0x4
subtracted before being used as the program counter. This was intended
to convert the return address (the instruction after a call) back to
the call site, but it is incorrect:
1. RISC-V has variable-length instructions due to the RVC (compressed
instruction) extension. A call instruction can be either 4 bytes
(regular) or 2 bytes (compressed, e.g. c.jal). Subtracting a fixed
0x4 assumes all call instructions are 4 bytes, which is wrong for
compressed instructions.
2. Stack traces conventionally report return addresses, not call sites.
Other architectures (ARM64, x86, ARM) do not subtract instruction
size from return addresses in their stack unwinding code.
3. The frame-pointer version of walk_stackframe already dropped the
-0x4 offset. Commit b785ec129bd9 ("riscv/ftrace: Add
HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support") replaced "pc =
frame->ra - 0x4" with ftrace_graph_ret_addr(), and the commit
message explicitly noted that "the original calculation, pc =
frame->ra - 4, is buggy when the instruction at the return address
happened to be a compressed inst." The non-FP version was simply
overlooked.
Remove the bogus -0x4 offset to match the FP version and the
conventions used by other architectures.
Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
Signed-off-by: Rui Qi <qirui.001@bytedance.com>
Link: https://patch.msgid.link/20260603115329.791603-2-qirui.001@bytedance.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Currently, the while loop drops the reference to prev in each iteration.
If the loop terminates early due to a break, the final of_node_put(np)
correctly drops the reference to the current node.
However, if the loop terminates naturally because np == NULL, calling
of_node_put(np) is a no-op. This leaves the last valid node stored in
prev without its reference dropped, resulting in a node reference leak.
Fix this by changing the final `of_node_put(np)` to `of_node_put(prev)`.
Fixes: 94f9bf118f1e ("RISC-V: Fix of_node_* refcount")
Cc: stable@vger.kernel.org
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Zishun Yi <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260509074040.1747800-1-vulab@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
When kexec_file_load places segments with buf_max=ULONG_MAX and
top_down=true, they land at the highest available physical addresses.
On RISC-V the size of the linear mapping is determined by the active
VM mode: SV39 caps the direct map at roughly 128GB, while SV48/SV57
extend the range substantially further. When the installed physical
memory exceeds the direct map size of the active mode, top-down
placement puts DTB/initrd at physical addresses outside the linearly
mapped region. The kexec'd kernel cannot reach them during early
boot, triggering a page fault at memcmp in start_kernel.
Fix by constraining buf_max to PFN_PHYS(max_low_pfn), which reflects
the runtime direct map boundary for the active VM mode (SV39/SV48/
SV57). This keeps all kexec segments within the linearly mapped
region while preserving the upstream top_down allocation strategy.
Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Link: https://patch.msgid.link/20260519170641.123517-1-gaohan@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
On RISC-V, the actual mappable range of physical address space is
dependent on the current MMU mode i.e. satp_mode (See
Documentation/arch/riscv/vm-layout.rst).
Define the DIRECT_MAP_PHYSMEM_END macro based on the existing virtual
address space layout macros to expose this information to
get_free_mem_region(). Otherwise, it returns a region that couldn't be
mapped, which breaks ZONE_DEVICE.
Cc: stable@vger.kernel.org # v6.13+
Tested-by: Han Gao <gaohan@iscas.ac.cn> # SG2044
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://patch.msgid.link/20260309-riscv-sparsemem-vmemmap-limits-v1-2-f40efe18e3cd@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Enable support for Eswin SoCs in the default configuration, so that
defconfig kernel/DTs are bootable on Hifive Premier P550 Board.
Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Link: https://patch.msgid.link/20260603-eswin_defconfig-v1-1-8471691d3153@oss.tenstorrent.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
If the ret.error equals to 0, the sbi_err_map_linux_errno() can also
handle it, i.e. if ret.error is SBI_SUCCESS, it will return 0
immediately, so no need to be bothered to check ret.error here.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://patch.msgid.link/20260413123515.48423-2-hui.wang@canonical.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
In the original sbi_cpu_is_stopped(), if rc doesn't equal to the
SBI_HSM_STATE_STOPPED, it will return rc to the caller directly. But
there is a hidden problem, the rc could be SBI_HSM_STATE_STARTED, if
so, this function will report cpu stopped while the cpu isn't really
stopped.
Furthermore, from the name of cpu_is_stopped(), it gives a sense the
return value is a bool type, true means the cpu is stopped, conversely
false means the cpu is not stopped.
Here change the return value type to bool and change the callers
accordingly. This could fix the above two issues.
Fixes: f1e58583b9c7c ("RISC-V: Support cpu hotplug")
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://patch.msgid.link/20260413123515.48423-1-hui.wang@canonical.com
[pjw@kernel.org: cleaned up some of the pr_warn() messages]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Remove the pr_fmt macro as no pr_*() calls exist in this file. The
prefix string "kexec_image: " is also not appropriate for kexec_elf.c,
if pr_fmt is needed in the future, referring to kexec_image.c, a more
appropriate prefix like "kexec_file(elf): " can be added at that time.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://patch.msgid.link/20260525115159.100177-1-hui.wang@canonical.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
RISC-V already satisfies all prerequisites for build-time mcount sorting:
the sorttable host tool handles EM_RISCV in its machine-type dispatch, and
the __mcount_loc section entries are stored as direct virtual addresses in
the final vmlinux binary, so no relocation processing is required during
the sort step.
Select HAVE_BUILDTIME_MCOUNT_SORT so that BUILDTIME_MCOUNT_SORT is
automatically enabled when DYNAMIC_FTRACE is configured. This allows
sorttable to sort the __mcount_loc section at link time, making the
run-time ftrace initialisation path skip the software sort and reducing
kernel startup overhead.
Verified with CONFIG_FTRACE_SORT_STARTUP_TEST=y, which confirms that
the section produced by the build is already in ascending order:
[ 0.000000] ftrace section at ffffffff81015a60 sorted properly
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
Tested-by: Guo Ren <guoren@kernel.org>
Link: https://patch.msgid.link/20260409114736.907-1-cp0613@linux.alibaba.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
The same Kconfig statement 'depends on RISCV_ISA_V' appears twice for
RISCV_PROBE_VECTOR_UNALIGNED_ACCESS. The first instance is in its choice
menu, "Vector unaligned Accesses Support", making the second instance in
its specific Kconfig definition dead code. I propose removing this second
instance.
This dead code was found by kconfirm, a static analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Jesse Taube <mr.bossman075@gmail.com>
Link: https://patch.msgid.link/20260329203249.563434-1-julianbraha@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
RANDOMIZE_BASE currently selects RELOCATABLE even though RELOCATABLE
is visible to users. Some other architectures, like x86, use 'depends on'
for RELOCATABLE in their definition of RANDOMIZE_BASE, so let's do the same
here.
This select-visible Kconfig misusage was detected by Kconfirm, a static
analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260503040331.71875-1-julianbraha@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
RISC-V KVM has used the hugetlb VMA size directly as the G-stage
mapping size since stage-2 page table support was added. That is safe
only if the block covered by the fault is fully contained in the
memslot and the userspace address has the same offset as the GPA
within that block.
The THP path already checks those constraints before installing a PMD
block mapping. The hugetlb path did not, so an unaligned memslot could
make KVM install a PMD or PUD sized G-stage block that covers memory
outside the slot or maps the wrong host pages.
Pass the target mapping size into fault_supports_gstage_huge_mapping().
The same helper can be used for both THP PMD mappings and hugetlb
PMD/PUD mappings.
Select hugetlb mapping sizes through the same memslot-boundary check,
falling back from PUD to PMD to PAGE_SIZE. When a smaller hugetlb
mapping size is selected, fault the GFN aligned to that selected size
instead of the original VMA size.
Also keep hugetlb mappings out of transparent_hugepage_adjust(). Once
the hugetlb path has chosen PAGE_SIZE, promoting it again through the
THP helper would miss the hugetlb fallback decision.
Fixes: 9d05c1fee837 ("RISC-V: KVM: Implement stage2 page table programming")
Signed-off-by: Jinyu Tang <tjytimi@163.com>
Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260604142602.3582602-2-tjytimi@163.com
Signed-off-by: Anup Patel <anup@brainfault.org>
|
|
Both GCC [1] and Clang [2] consider the generic version of _THIS_IP_ to
be broken:
#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
In particular, the address of a label is only expected to be used with a
computed goto.
While the generic version more or less works today, it is known to be
brittle and may break with current and future optimizations. For
example, Clang -O2 always returns 1 when this function is inlined:
static inline unsigned long get_ip(void)
{ return ({ __label__ __here; __here: (unsigned long)&&__here; }); }
Fix it by overriding _THIS_IP_ in <asm/linkage.h> (which is included by
<linux/instruction_pointer.h>) using an architecture-specific inline asm
version. Additionally, avoiding taking the address of a label prevents
compilers from emitting spurious indirect branch targets (e.g. ENDBR or
BTI) under control-flow integrity schemes.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071 [1]
Link: https://github.com/llvm/llvm-project/issues/138272 [2]
Signed-off-by: Marco Elver <elver@google.com>
Link: https://patch.msgid.link/20260521000436.3931067-1-elver@google.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
The module-sections.c file defines a custom cmp_3way() macro to perform
3-way comparisons during relocation sorting.
Instead of maintaining our own implementation, use the generic
cmp_int() macro provided by the already included <linux/sort.h>. This
removes redundant code and relies on standard kernel interfaces.
Signed-off-by: Florian Schmaus <florian.schmaus@codasip.com>
Link: https://patch.msgid.link/20260512063231.708256-1-florian.schmaus@codasip.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
The walk_stackframe() function is used to unwind the stack of a given
task. When function graph tracing is enabled, ftrace_graph_ret_addr()
is called to resolve the original return address if it was modified by
the tracer.
The current code incorrectly passes 'current' instead of 'task' to
ftrace_graph_ret_addr(). This causes incorrect return address resolution
when unwinding a stack of a different task (e.g., when the task is
blocked in __switch_to).
Fix this by passing 'task' instead of 'current' to match the behavior
of other architectures (arm64, loongarch, powerpc, s390, x86).
Signed-off-by: Rui Qi <qirui.001@bytedance.com>
Link: https://patch.msgid.link/20260408092915.46408-1-qirui.001@bytedance.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
The generic CC_CAN_LINK detection relies on -m32/-m64 compiler flags.
These are not supported by riscv compilers.
Use architecture-specific logic using -mabi instead.
Prefer the 'd' ABI variant when possible as todays toolchains are most
likely to provide a libc for that one.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260316-cc-can-link-riscv-v4-1-64c072b456dd@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Currently, add_resource() returns 1 on success, even though its callers
only check for negative values. Instead, propagate the insert_resource()
result from add_resource() to align with standard kernel return-value
conventions (0 on success, negative errno on failure).
Use %pR to print the full resource range while at it.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260512172034.328405-4-thorsten.blum@linux.dev
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Replace sprintf() with sysfs_emit() in cpu_show_ghostwrite(), which is
preferred for formatting sysfs output because it provides safer bounds
checking.
While the current code only emits fixed strings that fit easily within
PAGE_SIZE, use sysfs_emit() to follow secure coding best practices.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260510165420.109453-3-thorsten.blum@linux.dev
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Use the return value of strscpy() instead of calling strlen(fdt_cmdline)
again and return early on string truncation. Drop the explicit size
argument since early_cmdline has a fixed length, which strscpy()
determines using sizeof() when the argument is omitted.
Replace strlcat() with strscpy() to append CONFIG_CMDLINE.
Also remove the unnecessary fdt_cmdline NULL initialization.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260504154924.141566-3-thorsten.blum@linux.dev
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Replace the unbounded sprintf("%s", ...) with the faster and safer
strscpy(). Replace all other sprintf() calls with the safer snprintf().
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260127110543.436242-1-thorsten.blum@linux.dev
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Add arch/riscv/include/asm/purgatory.h and provide the purgatory()
prototype via the architecture header, mirroring the x86 layout.
Remove the workaround from arch/riscv/purgatory/purgatory.c.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260509073850.44595-4-thorsten.blum@linux.dev
[pjw@kernel.org: drop superfluous extern in header file]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
Change the function's return type from int to bool and return the result
of memcmp() directly to simplify the code. While at it, cast ->start to
'const u8 *' to better match the expected type.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260509073850.44595-3-thorsten.blum@linux.dev
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
prctl(PR_SET_CFI,PR_CFI_BRANCH_LANDING_PADS) silently ignored
unknown control values. Only PR_CFI_{ENABLE,DISABLE,LOCK} should
be permitted.
This changes the behavior of the uABI (fails previously accepted bits
with EINVAL).
Fixes: 08ee1559052b ("prctl: cfi: change the branch landing pad prctl()s to be more descriptive")
Signed-off-by: Richard Patel <ripatel@wii.dev>
Link: https://patch.msgid.link/20260518183918.322545-1-ripatel@wii.dev
[pjw@kernel.org: change the patch description to note that although this is a uABI change, it does not break the uABI]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
